Hello and welcome to my blog which details the path to root on the https://www.hackthebox.eu machine named POSTMAN. As per the rules, this is a retired machine and The IP Address of this machine was 10.10.10.160 at the time of exploiting.
The first step in any engagement is reconnaissance. We want to see what services are running on the host, and to do this, I like to use the following command:
‘nmap --top-ports 5000’
Very simply, this NMAP command will scan the host for the top 5000 common ports, and typically yields much quicker results than scanning all 65535 ports. It also provides a bit more accuracy than scanning just the top 1000 ports. At this stage we are just looking for something to work with, a full scan can come later, if need be.
As shown above, we have discovered a few ports to analyse. An important note here is that the REDIS port would not have been found in a NMAP top 1000 scan, this shows how easy it is to miss ports sometimes, so be thorough!
Let’s look at the services we have available to us. We’ll leave SSH, as this service rarely is the first step to compromise. Port 10000 looks interesting. I always start by browsing to the ports in a web browser to see if they have web GUIs. Browsing to this port via HTTP gave the following:
Then browsing to this port using HTTPS gave us a bit more:
From this GUI and Googling the name, we can determine that this is POSTMAN Webmin.
WEBMIN VULNERABILITY SEARCH
Googling ‘Postman Webmin Vulnerabilities’ showed us that quite a few actually exist, as shown in the following URL:
By using Google to search for exploits using the URL above, this lead me to ExploitDB.com. It was also apparent that Metasploit exploits exist for this application:
So let’s search the Metasploit DB on Kali for Webmin:
There’s a few we can use. By looking at the dates, we know two are from 2012 and one is from 2006, which would be too old for this version of Webmin. I knew this as I Googled Webmin 2012 and it looked like this:
It’s clear that this login box looks less current than the version we saw earlier. Therefore, that leaves us with three potential exploits we can use on this version of Webmin:
- exploit/linux/http/webmin_packageup_rce -Webmin Package Updates RCE
- exploit/unix/webapp/webmin_backdoor – Webmin password_change.cgi Backdoor
- exploit/unix/webapp/webmin_upload_exec – Webmin Upload Authenticated RCE
I tried exploit 2 first, as this did not require a username and password. This was not successful.
At this point, it was thought that we may need to park this route for now and find a legitimate user, then maybe use this later to end up with root.
From our initial port scan, we found three other ports further to port 10000 which we just looked at earlier.
These are ssh (22), http (80) and REDIS (6379). We’ll as I said before, we’ll rarely get anywhere with ssh, let’s look at port 80:
Taking a quick look at the source code showed nothing
particularly interesting. We could enumerate directories, but I believed we
should look at REDIS before beginning to do anything with port 80.
REDIS sits on port 6379, it’s essentially a database. To interact with REDIS effectively, you can use redis-cli. This comes packaged with REDIS server, or you can download just the CLI here: https://github.com/holys/redis-cli
Once downloaded, I tried connecting to REDIS with ‘redis-cli -h 10.10.10.160’. To my surprise, no password was required:
I’ve never used REDIS before, so was interested in which commands I would need to use. A quick Google and here’s what I found, and this will be all you need for this task:
- KEYS * – Show all keys in the database
- KEYS key – Shows value of specific key
- SET key “DATA” – Inputs data into a specific key (Can be used to overwrite keys)
- GET key – Used to view a specific key.
- flushall – remove all database keys.
There was obviously going to be a purpose of REDIS being here, something we’d have to do. So, when you think about the concept that REDIS is a key store, I thought about SSH keys. This may have been a lucky guess, but I Googled REDIS and SSH and found what I needed to do here:
You can follow this guide, but essentially what you need to do is generate an SSH key pair and use REDIS to write your SSH public key to the REDIS
The URL describes that REDIS will cause some corruption to this file, so we will need to pad this corruption out, to make the SSH key readable. You can do this with newlines such as ‘\n\n\n\n\n’ before and after your RSA key. Like so:
“\n\n\n\nssh-rsa AAAAB3NzaC1yc2EffssJQAssAx9LMtudax9JbVQs/r+1bfrA6sFrJ/TadsakihWe+1BlRmYWJR6dcbcOjLHBDfGfw1JN2numFxwkzr0v1xJq8m6icT7PtaB5xbhHadsdo2Xyx+NWBPigQ+zW2zKdJ5HafgBOK6gznVhoo6H3iUsZBLbK5Rk0Qgi8IExNyK8S6ijfsdfee9f8fNUDcovrgbcUfsdfgsdderMasdasdhfsJLfDeGRGWOTIhRydas/IGajVziVJYTs2IIivEi5Y1bNMHxpInddddzQvv5rWXzb5sVGSFfz8oTdasKRAOvxf3+Z2wvPXh+Rhu/qmvDoxQ== [email protected]\n\n\n\n“
The URL above tells us to use the following commands:
cat foo | ./redis-cli -h 10.10.10.160 -x set crackit
redis-cli -h 10.10.10.160
config set dir /Home/User/.ssh
config get dir
config set dbfilename "authorized_keys"
However, the problem that I came across was that the REDIS
.ssh folder was not in the usual home directory of /home/REDIS. So, Googling the installation directory of REDIS, we can determine it is
/var/lib/redis/ and thus, it’s likely the
.ssh file will be there. I.E
This means for the second command you want to use
config set dir /var/lib/redis/.ssh
Once you have entered ’save’, your SSH key should be saved to the
authorised _keys file. This means you should be able to SSH into the box. You will need to provide your private key which matches the public key you just entered here. The command for this is:
ssh -i PrivateKeyFile [email protected]
At this point, you are logged in as the REDIS user. Now let’s go and find the users.txt file. Upon using
cd ~/ to get to the home folder, it was seemingly not there. After looking at the other home folders, a user called Matt was discovered. Clearly we’re going to have to do some escalation.
I looked at the running processes, nothing of real interest was seen other than the root user, whom is running webmin. This is an issue we exploit later. I looked at the cronjobs, nothing. I tried to access
/etc/shadow for the password hashes, denied. I then looked at the bash history:
The interesting part of the history, shown above, is that a backup of an SSH key exists somewhere (id_rsa.bak) and REDIS has been logging into by Matt as he used ‘su to access his account’. I used the following command to find the SSH key backup file:
find / -type f -name "id_rsa.bak"
The key was located in the
/opt/ folder. Now we have the RSA key and the knowledge that this key might work with Matt, SSH login was attempted. It was instantly discovered that the key had a password, so we couldn’t login yet. I also looked at the SSHD config file, and this denied login ability for the Matt user. Due to this, it was clear why Matt used
su via the REDIS user.
So, how do we get a password? We crack the RSA key which we found using John. In Kali, browse to
/usr/share/john and use the private key we found with
ssh2john.py like so
ssh2john.py /MattID > MattID.hash
Now we can crack the gained hash with john using
/usr/sbin/john –wordlist=/usr/share/wordlist/rockyou.txt MattID.hash You’ll find that the password is “computer2008”
As we now have the password for Matt, we can use the command
su Mattvia REDIS and be logged in as the Matt user. From here you can simply
cd to the Matt home directory and cat the flag:
Nice, that’s the user flag sorted.
Earlier we found that Webmin has exploits which required a username and password. With this knowledge, the first thing to do was try one, so I tried Metasploit with
Shown above, I have input the Matt username and password, turned SSL to true and set the RHOSTS to the IP address of the server. I have also set my VPN IP Address in the payload options to gain a reverse shell back to me. At this point, I ran the exploit with ‘run’:
Success! Let’s see who the user is:
I’m root, this was due to the Webmin server running as root, not good practice!
It was apparent that trying to change directory with ‘cd’ was not working for some reason. I skipped the hardship and simply
cat the root file, which we knew is likely to be in the root home directory, which is
/root on most Linux distributions:
There you have it, we gained the root flag and the box is completed. For more information on tools and ethical hacking in general, see my YouTube!