Pre- Foothold
Initial All port scan
Deep port
Login to Cacti looks interesting.
The version is a little behind here, lets see if we can find default creds, got nothing, creds must be setup on setup I think
Ran a gobuster, interesting directories but nothing that stands out or is readily accessible
Found a RCE that corresponds with the exact version of Cacti, also sends back a shell.
Let’s give it a shot. Runs on python 3 so we take the raw code and put it into a python script.
I tried this but ran into a lot of errors that could have something to do with one of the libraries that was imported. I could work through this, but let’s see if metasploit has an available exploit.
That top one looks promising as it is unauthenticated command injection and it matches the version of cacti we are targeting.
select the exploit then set the necessary options and…
No dice. I fumble around with this for a bit as well and got nowhere. I decided to check github and found a CVE for this version of cacti.
So I setup a listener, run the exploit and…
We are in there like swimwear
I bounce around for a while and don’t find a User flag. I end up finding out we are in a container based on the root files I see and the hostname following the original exploit
However there is an entrypoint.sh there. I find out later after some searching that this is common with containers. Once I cat the script I find credentials and a command there I can use to navigate the database.
That’s a dump from the user_auth table that was found after running the command on line 4. Going to take the hashes from marcus and admin and see what I can crack using john.
Started by echoing the hash into a file and running John the ripper to see if I can get a cracked password. John sees the hash as bcrypt, so let’s hope it runs and gives us the goods.
Got it
Ok! With this new information and the username we pulled from the database we try to ssh into the server and…
Foothold complete! The flag was in the users home directory.
Post Foothold
Upon login I noticed this message.
Mail you say? Let’s take a look.
This isn’t installed and I can’t install anything or run sudo. Another check of the home folder reveals a bash script.
This script looks like what it’s doing from the top down is first getting the version of docker then checking if it is vulnerable to CVE-2021-41091. If it is vulnerable it allows you to set a suid bit on /bin/bash in the docker container to spawn a root shell.
My thoughts is this script was left behind by another user attempting to hack this box. On the free tier of HTB multiple users can access the same instance. I didn’t want to just arbitrarily run this script, so I took a look at it before running.
Let’s check out this CVE to see what it is exploiting in docker!
Ah those pesky insufficient permissions. TL;DR There is a directory in the Moby project (a docker engine) that had subdirectories with insufficient permissions and a user could execute programs in that directory to get root access.
Ok, now that we know what is going on we still have an issue, we don’t have root access in the container!
So I stumbled around a bit and checked the host, trying to connect to the docker container or get info on it, but our user marcus can’t do a damn thing with docker. Getting permission denied all over!
So eventually I backtrack and go back into the container the only way I know how, with the previous cacti exploit. While in the container I did a search for binaries with the SUID bit set and found one that looks interesting!
A quick search on gtfo bins and I find I can drop into a root shell which means I can set the SUID bit on /bin/bash and get root using the previous exploit script exp.sh
Back on the host I run the exploit again and…
pwned :)
Thanks for reading!