LinkedInExploit ADHackTheBox

Tomcat

  • Apache Tomcat is an open-source web server that hosts applications written in Java.

  • Tomcat was initially designed to run Java Servlets and Java Server Pages (JSP) scripts. However, its popularity increased in Java-based frameworks and is now widely used by frameworks such as Spring and tools such as Gradle.

  • According to data gathered by BuiltWith there are over 78,000 live Tomcat websites at this time.

  • BuiltWith has gathered data that shows that over 704,000 websites have at one point been using Tomcat

  • 1.22% of the top 1 million websites are using Tomcat, while 3.8% of the top 100k websites are

  • Tomcat holds position # 13 for web servers by market share

  • Some organizations that use Tomcat include Alibaba, the United States Patent and Trademark Office (USPTO), The American Red Cross, and the LA Times

Footprinting

Tomcat servers can be identified by the Server header in the HTTP response. If the server is operating behind a reverse proxy, requesting an invalid page should reveal the server and version. Here we can see that Tomcat version 9.0.30 is in use.

Custom error pages may be in use that do not leak this version information. In this case, another method of detecting a Tomcat server and version is through the /docs page.

This is the default documentation page, which may not be removed by administrators. Here is the general folder structure of a Tomcat installation.

  • The bin folder stores scripts and binaries needed to start and run a Tomcat server.

  • The conf folder stores various configuration files used by Tomcat.

  • The tomcat-users.xml file stores user credentials and their assigned roles.

  • The lib folder holds the various JAR files needed for the correct functioning of Tomcat.

  • The logs and temp folders store temporary log files.

  • The webapps folder is the default webroot of Tomcat and hosts all the applications.

  • The work folder acts as a cache and is used to store data during runtime

Each folder inside webapps is expected to have the following structure.

The most important file among these is WEB-INF/web.xml, which is known as the deployment descriptor. This file stores information about the routes used by the application and the classes handling these routes. All compiled classes used by the application should be stored in the WEB-INF/classes folder. These classes might contain important business logic as well as sensitive information. Any vulnerability in these files can lead to total compromise of the website. The lib folder stores the libraries needed by that particular application. The jsp folder stores Jakarta Server Pages (JSP), formerly known as JavaServer Pages, which can be compared to PHP files on an Apache server.

Here’s an example web.xml file.

The web.xml configuration above defines a new servlet named AdminServlet that is mapped to the class com.inlanefreight.api.AdminServlet. Java uses the dot notation to create package names, meaning the path on disk for the class defined above would be:

  • classes/com/inlanefreight/api/AdminServlet.class

Next, a new servlet mapping is created to map requests to /admin with AdminServlet. This configuration will send any request received for /admin to the AdminServlet.class class for processing. The web.xml descriptor holds a lot of sensitive information and is an important file to check when leveraging a Local File Inclusion (LFI) vulnerability.

The tomcat-users.xml file is used to allow or disallow access to the /manager and host-manager admin pages.

The file shows us what each of the roles manager-gui, manager-script, manager-jmx, and manager-status provide access to. In this example, we can see that a user tomcat with the password tomcat has the manager-gui role, and a second weak password admin is set for the user account admin

Enumeration

After fingerprinting the Tomcat instance, unless it has a known vulnerability, we'll typically want to look for the /manager and the /host-manager pages. We can attempt to locate these with a tool such as Gobuster or just browse directly to them.

Attacking Tomcat

Tomcat Manager - Login Brute Force

We can use the auxiliary/scanner/http/tomcat_mgr_login Metasploit module for these purposes, Burp Suite Intruder or any number of scripts to achieve this. We'll use Metasploit for our purposes.

Some say, "work smarter, not harder." Why would we make extra work for ourselves during a 40-hour assessment with 1,500 in-scope hosts when we can use a particular tool to help us? It is vital for us to understand how our tools work and how to do many things manually. We could manually try each credential pair in the browser or script this using cURL or Python if we choose. At the very least, if we decide to use a certain tool, we should be able to explain its usage and potential impact to our clients should they question us during or after the assessment.

We can use Burp or Zap and setup a proxy to see whats happening under the hood:

We can see in Burp exactly how the scanner is working, taking each credential pair and base64 encoding into account for basic auth that Tomcat uses.

Tomcat Manager - WAR File Upload

Many Tomcat installations provide a GUI interface to manage the application. This interface is available at /manager/html by default, which only users assigned the manager-gui role are allowed to access. Valid manager credentials can be used to upload a packaged Tomcat application (.WAR file) and compromise the application. A WAR, or Web Application Archive, is used to quickly deploy web applications and backup storage.

The manager web app allows us to instantly deploy new applications by uploading WAR files. A WAR file can be created using the zip utility. A JSP web shell such as this can be downloaded and placed within the archive.

Click on Browse to select the .war file and then click on Deploy.

This file is uploaded to the manager GUI, after which the /backup application will be added to the table.

If we browse there directly we'll get a 404, so we need to add the .jsp file as well:

It will present us with a webshell and we can interact with it using cURL:

To clean up after ourselves, we can go back to the main Tomcat Manager page and click the Undeploy button next to the backups application after, of course, noting down the file and upload location for our report, which in our example is /opt/tomcat/apache-tomcat-10.0.10/webapps

Using MSFvenom

We could also use msfvenom to generate a malicious WAR file. The payload java/jsp_shell_reverse_tcp will execute a reverse shell through a JSP file. Browse to the Tomcat console and deploy this file. Tomcat automatically extracts the WAR file contents and deploys it.

The web shell as is only gets detected by 2/58 anti-virus vendors.

A simple change such as changing:

To:

results in 0/58 security vendors flagging the cmd.jsp file as malicious at the time of writing.

CVE-2020-1938 : Ghostcat

Tomcat was found to be vulnerable to an unauthenticated LFI in a semi-recent discovery named Ghostcat. All Tomcat versions before 9.0.31, 8.5.51, and 7.0.100 were found vulnerable. This vulnerability was caused by a misconfiguration in the AJP protocol used by Tomcat. AJP stands for Apache Jserv Protocol, which is a binary protocol used to proxy requests. This is typically used in proxying requests to application servers behind the front-end web servers.

The AJP service is usually running at port 8009 on a Tomcat server. This can be checked with a targeted Nmap scan.

The above scan confirms that ports 8080 and 8009 are open. The PoC code for the vulnerability can be found here. Download the script and save it locally. The exploit can only read files and folders within the web apps folder, which means that files like /etc/passwd can’t be accessed. Let’s attempt to access the web.xml.

In some Tomcat installs, we may be able to access sensitive data within the WEB-INF file.

PreviousServlet Containers/Software DevelopmentNextJenkins

Last updated