HackTheBox Writeup — Cache
Hack the Box is an online platform where you can practice your penetration testing skills. This is my write-up for the HackTheBox machine ‘Cache’, which runs a Linux OS and is one of the ‘medium’ rated machines.
The initial foothold on this box involves clever enumeration with cewl and wfuzz to find another virtual host, which reveals the OpenEMR web application, and then chaining together an SQLi vulnerability, password cracking and an authenticated RCE vulnerability to get ‘www-data’. We then escalate to the user ‘Ash’ using some previously identified credentials, and enumerate a local memcache server to get credentials for the user ‘Luffy’. Luffy is seemingly inside docker container, so we use a standard GTFObins one-liner to break out of this restricted environment and escalate to root.
2. Enumeration and Initial Foothold (www-data)
As always we start off with an Nmap scan to see what services are running. A handy tip is to store the machine’s IP address in an environment variable so we don’t have to type it in each time we need it, although this only applies to the current tab and needs to be repeated if extra tabs are open.
Only two ports open, SSH and HTTP, lets go and check out the web application.
A very basic website with a couple of links, including an author and login page. The login page is a barebones implementation and since we don’t have any credentials yet, let’s check out the author’s page.
Some interesting information to be grabbed here, including the author’s name (Ash), a hostname (cache.htb) and maybe a hint to checkout Ash’s other project HMS. Perhaps we can access this if we can login?
After failing with some default credentials, I decided to look at other files that are loaded with this web application and found an interesting ‘functionality.js’ file.
Awesome! The website only performs a client-side check for user credentials. However, logging-in with these credentials provides nothing useful, just another web page.
I then took a look back at the author page and specifically the hostname ‘cache.htb’ and wondered whether Ash’s other project has a separate hostname (i.e. virtual host). To check this I created a wordlist from the author.html page and ran a wfuzz scan to fuzz for other hostnames associated with the IP address 10.10.10.188.
To get the correct format to fuzz for the hostname, I had to refer back to the network tab within the web developer tools to see the request, although this could have also been done in BurpSuite.
HMS gives a 302 redirect. Adding ‘hms.htb’ to the /etc/hosts file to associate this virtual hostname with the IP address 10.10.10.188 we get the OpenEMR web application.
I began to research exploits for OpenEMR but only found (authenticated) RCE exploits, meaning we had to find some credentials. Further research found an SQL Injection vulnerability at the following location:
Perhaps we can dump the database and any user credentials? Lets first get the vulnerable network request with BurpSuite, and save it into a text file to pass into SQLmap.
Now to identify the databases we can run SQLmap with the command below, which identifies two databases.
sqlmap -r burp_request.txt --threads=10 --dbs
Lets inspect the tables this database contains to try and find where the user credentials are stored.
sqlmap -r burp_request.txt --threads=10 -D openemr --tables
The final command to run with SQLMap dumps the data from the ‘users_secure’ table and we identify a username and password hash.
sqlmap .... --threads=10 -D openemr -T users_secure --dump
We can tell from the password hashes format that it is a ‘bcrypt’ style hash, so I ran this through JohnTheRipper and it cracked it easily. This gave us the following credentials to go log into the OpenEMR web application:
- username : openemr_admin
- password : xxxxxx
After logging into the OpenEMR web application, I used searchsploit and downloaded the authenticated RCE scripts, however I saw many HTB users complain that using these scripts (without explicit modification) were causing the box to break, so I opted for a safer route. That is, to find an area I can upload my PHP reverse shell code.
After much enumeration of the application I found the following PHP files accessible at:
With this uploaded I started a netcat listener on my machine, accessed the document at the location below and obtained a reverse shell as www-data.
3. User — Ash
Phew, that was long.
Thankfully escalation to Ash is super easy, we can simply use the credentials identified in the ‘functionality.js’ file previously and grab the user.txt flag.
4. User — Luffy
After performing some enumeration with LinPeas, I noticed that the box was listening for connections locally on port 11211. This port is associated with Memcached servers and would be fitting considering the name of the box.
Using Raj Chandel’s blog post on penetration testing memcached servers as a reference point, I connected to the port as ‘Ash’ with telnet and managed to extract user credentials for Luffy.
One thing I noticed earlier when running LinPeas was a lot of references to Docker, and although no docker instances are running, Luffy is a member of the docker group.
GTFObins documents a method to run and bind the host’s OS to the docker container’s /root . Firstly I checked the docker images available on the machine and we find ‘ubuntu’. This is the only thing we need to change from the GTFObins one-liner, although I did also change the shell to spawn from ‘sh’ to ‘bash’.
Running this one-liner gives us a root shell where we can grab root.txt.
Thanks for reading and keep an eye out for future writeups! Feedback is always welcome, and my HackTheBox profile is linked below.