Welcome to another Forest Hex hacking adventure! 🌲🏹

Today I will be hacking a box named Postman.

Feel free to jump around as always:

• Port Scan
• Investigating Open Ports
• Finding a Foothold
• Escalating to a user shell
• Getting Root

Port Scan

Let’s dive right in with a port scan: nmap -p- -sC -sV --min-rate=1000 -T4 10.10.10.160

Looks like I have a few avenues of attack here. Webmin on port 10000 interests me greatly, I remember a lot of webmin exploits existing the last time I searched for them. My gut is to always check port 80 first though:

Investigating Open Ports

Port 80:

Port 1000:

A suggestion to try SSL protocol, alright then…

A Webmin login page, cool. I messed around a bit here with some SQL injection and default password combos but got nowhere, I wasn’t expecting it to but you never know.

Port 6379

Interesting… I worked with Redis a while back, it’s a way to store key value pairs on a server that you can interface with over HTTP requests. I looked up how to list all key value pairs: https://chartio.com/resources/tutorials/how-to-get-all-keys-in-redis/

So I need to figure out how to send this command, maybe I can just use netcat.

Paydirt, though I’m not sure what it’s for yet. Cracklist sounds interesting…

Hm, a public ssh key, interesting. I’ll save it in CherryTree for now.

Well the initial enumeration is done, time to search for some exploits.

It turns out that this SSH key was from another hacking attempt, I just did not realize it at the time.

Finding a Foothold

First I decided to use searchsploit for a Webmin exploit:

The highlighted one seems perfect, according to NMap the versions is 1.910. It’s a metasploit module which means it could be easy to use, but you never know. I read the details on this exploit, it’s clear we need credentials first: Any user authorized to the "Package Updates" module can execute arbitrary commands with root privileges.

That could be something we use later, but for now it’s time to move somewhere else. The other exploits for versions above 1.910 are worth investigating.

This one sounds promising: https://www.exploit-db.com/exploits/47230

This module exploits a backdoor in Webmin versions 1.890 through 1.920. Only the SourceForge downloads were backdoored, but they are listed as official downloads on the project's site

It could work, the chances are lower for our version however according to the details. Well, we can check it pretty quickly with metasploit so let’s do that.

Bummer. The other one listed was the same exploit, just a different version so that won’t work either. That leaves me with Apache exploits, which are usually a dead end in my experience.

The Redis Modules RCE Exploit

After checking out searchsploit I confirmed there are no suitable apache exploits here. My gut points me back at the redis server, I’m going to install redis-cli to see what I can find.

Running the INFO command in netcat got me the version number: redis_version:4.0.9

Poking around in the actual client led me to believe the cracklist variable was a fluke. There’s also an exploit I found for redis 4/5 that has RCE, I’m going to try it out.

Oh yeah, that’s what I like to see. Time to cross my fingers and run exploit.

Close but no cigar… I played around a bit and decided to manually listen on netcat but that didn’t work either. I did some more research and decided to update metasploit, if this fails I’ll try to understand the exploit manually and see if there’s a non-metasploit version.

After a bit of searching I found a python version: https://github.com/Ridter/redis-rce

I also found a very detailed explanation of how the redis rogue server exploit works: https://medium.com/@knownsec404team/rce-exploits-of-redis-based-on-master-slave-replication-ef7a664ce1d0

Adding an SSH key vis Redis

After a ton of playing around with these exploits and understanding them better I realized this type of exploit won’t work due to the lack of supports for MODULES on the other system.

I did realize I have some alternate paths to a shell however, since I can write files to the other system I can try to stick a bash shell in a crontab, or a php shell on the www server, or an SSH key somewhere.

I managed to find this tutorial https://medium.com/@Victor.Z.Zhu/redis-unauthorized-access-vulnerability-simulation-victor-zhu-ac7a71b2e419

On top of that, playing around with the redis client allowed me to find the config file was already present at /var/lib/redis/.ssh

I created a public key and followed the tutorial.

Basically it works like this:

1. Get redis-cli. https://redis.io/topics/rediscli
2. Wrap newlines around a public key. (echo -e "\n\n"; cat ~/.ssh/id_rsa.pub; echo -e "\n\n") > temp.txt
3. Save the formatted key in Redis. cat ~/.ssh/temp.txt | redis-cli -h 10.10.10.160 -x set s-key
4. Connect with redis-cli interactive mode. redis-cli -h 10.10.10.160
5. Set redis save directory to .ssh folder. CONFIG SET dir /var/lib/redis/.ssh
6. Set redis db name to authorized_keys. CONFIG SET dbfilename authorized_keys
7. Save it. save

This saves a public key to the redis server, which is then saved in the db filename under the configured dir. It ends up having the ssh public key value here: /var/lib/redis/.ssh/authorized_keys

Redis will append some metadata to the top, that’s why the public key was wrapped in newlines. OpenSSH will manage to parse the public key correctly since it just checks every newline for a valid key, ignoring invalid entries. The metadata is ignored, and the real public key is loaded.

This allowed me to SSH into the system as redis using my key, which seems a bit strange. I checked out /etc/passwd and confirmed redis is set up to use bash on login, this is definitely towards the CTF style of things. You normally wouldn’t allow the redis service to have a bash login.

I eventually figured out this was the method when I realized the previous cracklist key I had found was attempting to do this very method of gaining access.

Escalating to a user shell

Once I was in I came across a file matt was running:

It looks like I can just put files on the server under his name. Well, I can probably stick a new authorized_keys file under his SSH folder and gain access as him. There’s a problem though, the file isn’t running and if I start it as redis it won’t be able to write anywhere redis can’t.

I started poking around some familiar areas, and on a whim checked /opt. Lo and behold:

Time to crack this baby. There’s a python script named ssh2john which I used to convert the ssh key into a format John the Ripper here: https://github.com/koboi137/john

After that I just crack it with John and Rockyou: john hash -d --wordlist=/usr/share/wordlists/rockyou.txt

Bingo, looks like it’s computer2008. Well considering there are only 3 accounts with bash logins (Matt, Root, redis), hopefully it works for Matt at least if not root.

I think another option is to send it vi and then vi should open and I can escape to a shell.

None of that worked, and after some more frustration I decided to look at the sshd_config file…

#deny users
DenyUsers Matt

Well god damnit. No matter, maybe he reused this password for his account and I can just su into it.

Awesome, got ya Matt! Time to try for root.

Getting Root

I poked around for a bit looking for anything obvious, but came up empty. Then I ran the lse.sh script: https://github.com/diego-treitos/linux-smart-enumeration

Nothing extraordinary came up, but I noticed binaries running as root was green and it reminded me that webmin was running. I quickly tried the credentials Matt computer2008 on it, and bingo I was in. I checked what webmin was running as, and it’s root!

Remember that webmin exploit we checked out first? It required the webmin user to have creds, which we now do. Let’s try and get root with it.