Cache was a medium rated Linux box where enumerating a website found some hard-coded creds and a vhost that contained an Electronic Medical Records application. This EMR app had some SQL injection vulnerabilities that allowed a password hash to be dumped and cracked, gaining access to the EMR app. A PHP reverse shell was uploaded through the EMR app and those hard-coded creds found earlier came in handy to su to the user 'ash'. From there, creds for a user 'luffy' were pulled out of memcached. For root, I found two paths. The intended route was a Docker container escape. I added cache.htb to /etc/hosts and got started.
Enumeration
nmap scan:
Without creds, time to check out the web server:
News:
Author:
Login:
In short order I found some creds hardcoded in a js file:
These creds worked for the login screen but lead nowhere:
I ran gobuster on the site and got nowhere. I was a bit stuck until I looked a bit closer at the website:
I added hms.htb to /etc/hosts, tried opening it up in a browser and was greeted with a login page:
Initial Foothold
The previously found creds did not work here so I enumerated more with gobuster:
admin.php gave me a version number:
Googling around for vulnerabilties found this article which described multiple instances of SQL injection as well as an authentication bypass. The auth bypass was incredibly simple. First navigate to the registration page:
Then just change the URL to something else. In this case I chose the 'find_appt_popup_user.php' file:
Hitting the search button auto-filled some parameters in:
Knowing that there are SQL injection vulnerabilties, I put a 1' for one of the parameters and received an error:
I saved the working request in Burp as 'req.txt' and threw it at sqlmap with sqlmap -r req.txt -D openemr --tables to find some juicy looking tables:
A few sqlmap commands later, I got a password hash:
Cracked the hash:
The creds worked and I was in the EMR app:
There was a file upload function in the app so I uploaded a reverse shell 'rs.php':
I accessed http://hms.htb/sites/default/images/rs.php and caught a shell:
Ash's password worked and I was able to su to him:
User flag:
User Pivot
While enumerating the system, I spied memcached being run on port 11211:
I had never worked with it before so I googled around and found this very helpful article. I connected to it with netcat and ran a test command stats slabs:
A few moments later, I ran get user and got some creds:
The creds worked and I now had a shell as luffy:
Privilege Escalation - Intended Route
My notes are a bit fuzzy here so apologies, but during enumeration, Docker was found to be running on the system. Googling around eventually lead me to this PoC of a Docker escape. The requirements were to have root access in the container, which we do have. I had issues getting a working exploit (which is why my notes suffered here). I tried various reverse shells, msfvenom payloads and none worked - they would all connect back to me as luffy instead of root. What finally did the trick was the following C code:
The compilation:
I changed the PoC code as follows:
This would change /tmp/t3chnocat to be owned by root and also make it a SUID binary. I built the binary and moved/renamed:
Transferred the files via scp:
As expected, we see both files are owned by luffy:
Now let's run the Ubuntu docker image:
In another shell, list the active containers and copy the t3chnocat-suid file over to the container:
Run the file in the container:
Run /bin/sh from the host:
In the container we see that something happened:
Check the /tmp folder and see that the 't3chnocat' binary is now a SUID owned by root:
Run the binary:
Catch a root shell:
Root flag:
Privilege Escalation - Unintended and Super Easy Route
After finding out that Docker was running, a trip to GTFOBins found this. Here I list the images and run the exploit:
BAM, root!
Taking a break
This will be my last writeup for a while as this was the last HTB box I finished before starting a new job. One of these days I'll have more time to play around on HTB again. Until then, keep hacking :D