Always stay close to what keeps you feeling alive!
Postman is an easy difficulty machine running Linux. It tests your knowledge in OSINT, Redis exploitation and basic Privilege Escalation through a known exploit. There is nothing overly complicated about this machine as long as you stick to basic enumeration and don’t get too carried away.
Be sure to checkout the Basic Setup section before you get started.
Like always, enumeration is our first port of call. Let’s take a look at the machine and see what we are dealing with.
From the output we see that we have a website on port 80 as well as redis on port 6379 and webmin on port 10000.
Doing a scan with Gobuster using the dir mode reveals some files and directories:
An interesting find is the upload directory!
Let’s checkout the website at http://postman.htb:
Nothing exciting. Let’s check the upload directory:
We find nothing useful and cannot find an upload form. Let’s move on for now.
Checking exploitdb for anything useful we find the following vulnerability relating to our webmin version:
Taking a look at this exploit we see that it requires valid credentials.
Let’s do a quick test and see if we can access redis without credentials using the tool redis-cli:
Looks promising! We can connect with redis-cli -h postman.htb -p 6379 where we find that we can change various settings using the config set command.
Having redis installed on our local machine allows us to research how redis is installed and configured. We find that a user named redis is created and the home directory for this default user is /var/lib/redis. So far seems we can only write with save in /var/lib/redis so we will focus on that area.
After a quick web search we find a vulnerability with misconfigured redis servers which may allow us to login via SSH. If you remember from our nmap scan the ssh port 22 is open.
Let’s give this a try:
First we create an RSA key pair:
Now let’s take our key and put it in a text file with new lines either side. I am assuming this is needed for when we parse it with redis:
We will now flush the Redis datastore:
And write the ssh.txt file we created in to a keystore on the Redis server via redis-cli command:
Now we will connect to the redis-server and set the dir option to /var/lib/redis/.ssh and confirm that the options have been updated successfully:
We then set the name of the file we want to save to the dir location and check that the options have been updated successfully:
Now for the moment of truth. Can we save our ssh key to the .ssh folder, let’s see:
Yes we can. The file was saved successfully.
Now to try logging in via ssh:
The first thing we notice is that there is no user.txt in the redis users home directory. A quick look in /home shows the directory Matt which contains the user.txt flag:
We will need to get access to the Matt account.
Having a look around /var/lib/redis we can see there is the usual .bash_history file of which we have read access.
Viewing the contents we see commands that have been executed by Matt:
We quickly notice the file id_rsa.bak. We are obviously going with an ssh theme here.
Let’s do a search for the file:
Nice. Let’s try and use it straight away and see if there is a passphrase:
Looks like Matt isn’t a complete idiot.
We will need to crack the key. John The Ripper will work well for this because we will need to convert the key to a readable format and john can do just that with ssh2john:
If you are using Kali you will find that ssh2john isn’t installed. You can download it from here.
Now let’s crack the hash:
Ok I take back what I said. Matt’s an idiot! Now let’s try and login via ssh locally from the redis shell:
Look’s like we have an issue. The passphrase worked but Matt may not be allowed to ssh in. This reminds me that there was a command in .bash_history where Matt was messing around with /etc/ssh/sshd_config the configuration file for the ssh server. Taking a look we can see Matt has logging in via ssh disabled:
Let’s try the password with su instead:
We can now grab the user flag in Matt’s home directory:
On to root!
Let’s go checkout the webmin exploit we saw earlier that required valid credentials may be the way to go.
One of those was Webmin 1.910 - 'Package Updates' Remote Command Execution (Metasploit) which is a Metasploit module:
And we are done :)
This machine was straight forward with sufficient research to establish how things work. Misconfigured Redis servers have been a real issue in the past and can still be found today in the wild. Overall this was an enjoyable machine.