HackTheBox Write-up — Postman

Jack Roberts
5 min readMar 14, 2020

--

This is my write-up for the HackTheBox machine ‘Postman’, which runs a Linux OS and is one of the ‘Easy’ rated machines. This is my first write-up so please feel free to give me some feedback on any good/bad points or areas that I could improve on, thanks in advance!

1. Postman Info Card.

1. Summary

The initial foothold on this box involves exploiting an unauthenticated Redis server to overwrite the SSH keys in the database with our own, allowing us to login via SSH as Redis. We move laterally to user ‘Matt’ using ‘su’ after cracking an RSA private key passphrase which also turns out to be the password for Matt’s user account. Finally, we compromise root by exploiting the web application ‘Webmin 1.910’ which is vulnerable to CVE:2019–12840 via Metasploit.

2. Enumeration and Initial Foothold

I firstly ran a full Nmap port scan against the Postman machine to identify the running services and open ports on this machine, enabling safe scripts (-sC) and service detection (-sV).

2. Postman Nmap Port Scan Results.

As shown above, there are four ports open. On port 22 we have SSH, on ports 80 and 10000 there are two web applications running and finally a Redis server on port 6379. Useful information obtained from this initial scan include the identification of the OS (Ubuntu), the web server types and versions (Apache 2.4.9 and MiniServ 1.910), and that Webmin is running on port 10000, which is a web application allowing administrators to manage Linux servers.

The web application on port 80 seemed to be a dead end as this had no interesting functionality or information. After realising the web application on port 10000 is running HTTPS, I was presented with the Webmin login page. After trying some default credentials that didn’t work, it’s clear I need to do some further enumeration.

3. Webmin Login Page

Since the only two ports left are SSH and Redis (6379), I did some background research on Redis Key Value Store 4.0.9 as I had not encountered this service before. The sources I found to be most helpful was the Redis documentation, or the linked article by Dace. After some further research it was apparent that this particular version of Redis was vulnerable to remote file writes if exposed (i.e. open port) and lacked authentication, meaning I could write some SSH files to the server and login as Redis.

To do this, I used the two commands below to generate some SSH keys and output the public key to a .txt file, with some necessary bogus data either side of the key.

  • ssh-keygen -t rsa -C jdr@example.com
  • (echo -e “\n\n”; cat id_rsa.pub; echo -e “\n\n” > jdr.txt

I then downloaded the redis-cli command line tool to allow me interact with the server and completed the remainder of the exploit, which is shown below.

4. Redis Exploit and Redis Shell Access.

2. Low Privilege User Shell — Matt

After obtaining a low privileged shell, I firstly output the contents of the /etc/passwd file to identify other users on the machine. From this, I identified two other users, Matt and Root. I enumerated this box manually and quickly came across a private key backup file in the /opt/ directory that was owned by Matt and was world-readable.

5. Matt’s RSA Private Key backup file.

After copying the contents of this file over to my local Kali machine into a new file, I ran this file (id_rsa) through ssh2john.py to output a new file (id_rsa.hash). This is because I plan to use John to crack the passphrase for this private key and to be able to do this, I need to convert the RSA private key into a format that John can understand. This process is shown below, along with the successfully cracked RSA private key passphrase which turns out to be: computer2008.

6. Cracking Matt’s RSA private key passphrase.

Now we potentially have a valid set of user credentials, I tried logging in via SSH but this didn’t work. Next I tried moving laterally using the ‘su’ command whilst still in the Redis shell and we successfully login as Matt with the credentials: [ Matt : computer2008 ].

7. Compromising Matt’s account and user.txt

3. Root

Upon obtaining extra privileges as Matt I tried running the LinEnum.sh script to quickly enumerate this machine, potentially looking for some Webmin credentials, however the only thing that stuck out was the Webmin was running with root privileges. From here I was confident that Webmin was my privilege escalation vector so I did some further research and found a number of potential exploits I could use if I got access to the Webmin console. I knew that Webmin allows authentication via local user accounts so tried Matt’s user credentials which turned out to be successful. I now had access to the Webmin console as an Administrator.

8. Webmin Console.

From here the version of Webmin running is re-confirmed at version 1.910, so after searching exploits associated with this version I found that this version is vulnerable to a Remote Command Execution vulnerability via the ‘package updates’ module should a malicious actor gain access to the web console as a system administrator. The link I found was a Metasploit module so I decided to use this to automate the exploit. The full exploit with altered parameters is shown below.

9. Webmin 1.910 Exploit Development

I run this with the parameters set and we get a root shell.

10. Root Shell and Root.txt

4. Conclusion

This was actually the third box I rooted from HackTheBox, with the first two being OpenAdmin and Traverxec. I thought this box was slightly harder than OpenAdmin and Traverxec, but it was still a lot of fun and allowed me to learn more about Redis and its potential vulnerabilities. Overall, a fairly easy box and a great starting point for people new to the HackTheBox platform.

Keep an eye out for my future write-ups!

--

--

Jack Roberts
Jack Roberts

Written by Jack Roberts

MSc Cyber Security Student at Lancaster University. Mostly posting CTF writeups from HackTheBox, TryHackMe and VulnHub.

No responses yet