![](/content/images/2020/03/image-61.png)
Postman was an easy rated box which was a short and fun romp. A vulnerability in redis lead to a low privilege shell then a ssh private key with a weak passphrase allowed lateral movement. Finally, password reuse combined with a Webmin exploit was used to get root access.
Enumeration
nmap scan:
![](/content/images/2020/03/image-62.png)
Let's check out http:
![](/content/images/2020/03/image-63.png)
Nothing stood out there so let's check out Webmin:
![](/content/images/2020/03/image-64.png)
This version of Webmin has vulnerabilities:
![](/content/images/2020/03/image-65.png)
The unauthenticated exploits did not work so I put this aside after trying creds like admin/admin, admin/password.
After doing a bit more enumeration on the website and turning up nothing, I ran a full port scan which discovered an open redis port:
![](/content/images/2020/03/image-66.png)
I connected to the redis port with netcat and confirmed that authentication was not needed:
![](/content/images/2020/03/image-67.png)
Initial Foothold
Searchsploit showed that there was a possible vulnerability:
![](/content/images/2020/03/image-70.png)
The Metasploit exploit did not work so a googling I went. I landed on this page talking about exploits based on master/slave replication exploits of redis but I had issues with redis modules not working. With a bit more searching I found this exploit that looked promising. Running it as-is gave a bunch of errors so at this point I installed redis-cli
to and did some more enumeration. Here I checked out the configuration:
![](/content/images/2020/03/image-68.png)
Towards the end of that I see an interesting path:
![](/content/images/2020/03/image-69.png)
Aha! The script on github was trying to write to the authorized_keys in /home/redis/.ssh:
![](/content/images/2020/03/image-71.png)
I changed some other paths to make things work - here's the diff between the original and mine:
![](/content/images/2020/03/image-72.png)
I tried running the script again and this time it worked without any errors, giving us a stable shell as redis:
![](/content/images/2020/03/image-73.png)
User Pivot
Redis' .bash_history file had some interesting activity:
![](/content/images/2020/03/image-74.png)
There are a couple of things to take away from this. The redis user uses the command su Matt
quite a bit. Also, 'id_rsa.bak' caught my eye. I started enumerating the system and eventually found this file in /opt:
![](/content/images/2020/03/image-75.png)
I copied and pasted the contents of this file into an id_rsa file on my system and tried to ssh in as Matt only to find it had a passphrase on it. ssh2john
was used to output a file that John The Ripper could crack:
![](/content/images/2020/03/image-76.png)
This file was cracked in short order:
![](/content/images/2020/03/image-77.png)
Trying to ssh in as Matt with the id_rsa file failed:
![](/content/images/2020/03/image-78.png)
However, the password worked for su
:
![](/content/images/2020/03/image-79.png)
User flag:
![](/content/images/2020/03/image-80.png)
Privilege Escalation
I took the creds over to Webmin was able to log in with Matt/computer2008:
![](/content/images/2020/03/image-81.png)
Remember the Webmin exploits from earlier that needed creds? I used this Metasploit exploit with the following options:
![](/content/images/2020/03/image-82.png)
Executing the exploit yielded a root shell:
![](/content/images/2020/03/image-83.png)
Root flag:
![](/content/images/2020/03/image-84.png)