The Jerry machine from the Hack The Box platform nicely illustrates the danger of weak and default credentials.
TL;DR
I obtained system-level privileges on Jerry by first finding weak administrative credentials to the Apache Tomcat Manager web application running on port 8080. Using those credentials, I abused built-in functionality within the Manager application to gain system-level shell access to the host.
Timeline of Notable Events
| Timestamp (UTC) | Event |
|---|---|
| 2021-09-15 17:22:04 PM | Assessment started |
| 2021-09-15 17:22:49 PM | Identified Apache Tomcat Manager application running on port 8080 |
| 2021-09-15 17:23:18 PM | Found weak credentials to the Manager application for the tomcat user |
| 2021-09-15 17:23:38 PM | Used the Manager application to upload a malicious war file, establishing a Metasploit reverse shell running as the NT AUTHORITY\SYSTEM user |
Attack Graph
This is the attack graph that represents what I did. I’ll walk through this in detail below:
Walkthrough
17:22:04 PM UTC: I started my assessment. I was provided the Jerry’s IP address, 10.10.10.95. I confirmed this machine was live with an nmap ping sweep.
I ran TCP and UDP port scans using nmap and found a single HTTP port open, 8080:
17:22:49 PM UTC: I crawled the web site running at port 8080 and found the default landing page for Apache Tomcat. Apache Tomcat is a very popular web server used to run Java-based web applications.
I tried to access the Manager application running within Tomcat but found that it required credentials to access.
17:23:18 PM UTC: I ran a default credentials scan using nmap and the nndefaccts script. I discovered that the Manager application could be accessed with the user tomcat and the password s3cret.
17:23:38 PM UTC: It is often the case that admin-level access to a web application results in obtaining shell access to the host running the web application. Attackers are well aware of different types of web applications and what kind of features they expose that can be abused to access the underlying host. This attacker technique, abusing admin-level web application privileges, is not really a vulnerability or misconfiguration — it’s simply the byproduct of having admin-level access in the first place.
The Manager application enables users to manage the life cycle of Java web applications run by the Tomcat web server. Users can deploy new applications, start them, stop them, and undeploy them. An attacker can abuse this functionality to deploy a malicious Java application. The malicious Java application can be used to execute arbitrary code within the Tomcat process running on the host.
To deploy a Java application within Tomcat, it must be first packaged up as a WAR (Web Application Archive) file. WAR files are essentially zip files containing Java code that adhere to a standard format.
The Metasploit framework contains a module, exploit/multi/http/tomcat_mgr_upload, that automates the process of generating a malicious WAR file and uploading it to a Tomcat server, given the username and password for a valid user. I used this module to deploy a malicious Java application that connected back to my own host and gave me a reverse shell. Within that reverse shell, I executed commands on the target host. The whoami command showed that I was running as NT AUTHORITY\SYSTEM, meaning the machine was fully compromised through the single tomcat user credential.
A Note on Cleaning Up
Responsible pentesters try not to leave traces of their activity lying around. In the case of the Tomcat exploit I ran using Metasploit, it was important to me to undeploy the malicious Java application that I had deployed and run. As part of doing this, I discovered that the Metasploit module I ran didn’t automatically undeploy the application, despite claiming to have done so. Upon further review, I noticed a bug in the Metasploit code related to the undeploy logic, and submitted a patch to the Metasploit git repo to fix it.
Conclusion
I fully compromised the Jerry machine in less than two minutes. To do this, I took advantage of two critical security flaws: first, weak administrative credentials for a web application, and second, the fact that this web application was running as a over-privileged system-level user. These two flaws are unfortunately common, and I see them routinely in real-world environments. Simple mitigations include setting up a strong password and creating a dedicated low-privilege service account to run the application.
