Tomcat is a popular web server that is frequently used in the corporate environment. It is installed, either as an independent solution or a servlet container, in various application servers (e.g. GlassFish or JBoss). The bug was discovered by a researcher at Chaitin Tech earlier this year. Apache Tomcat or Tomcat server is powerful, open-source Java Servlet Container that implements multiple Java EE specs including JavaServer Pages (JSP), Java Servlet, WebSocket, and Java EL. The application powers large-scale, mission-critical systems in a wide range of well-respected organizations and industries. If your organization is using Tomcat server chances are, you are handling. HTTP Request Smuggling vulnerability exists if Apache Tomcat is located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Affected Versions: Apache Tomcat 9.0.0.M1 to 9.0.30 Apache Tomcat 8.5.0 to 8.5.50 Apache Tomcat 7.0.0 to 7.0.99. Apache Licenses¶. The Apache Software Foundation uses various licenses to distribute software and documentation, to accept regular contributions from individuals and corporations, and to accept larger grants of existing software products.
From charlesreid1
- 1Tomcat Service
- 3Metasploit Modules for Tomcat
- 3.1Login Credentials
- 3.2Uploading Java Executable with Metasploit
- 3.3Uploading Java Executable Manually
We will attempt to abuse the Tomcat server in order to obtain access to the web server. The end goal is to obtain a shell on the web server.
Just a reminder of what the nmap scan returned about Apache Tomcat and Coyote:
JSP stands for JavaServer Pages. All this means is, web pages accessed through port 8180 will be assembled by a Java web application.
What is tomcat
Apache Tomcat provides software to run Java applets in the browser. The nmap scan didn't return the version, so that's probably the first thing we'll want to figure out.
What is coyote
Coyote is a stand-alone web server that provides servlets to Tomcat applets. That is, it functions like the Apache web server, but for JavaServer Pages (JSP).
From the description of Coyote on the Tomcat page [1], it sounds like this server will be as susceptible to denial of service attacks as the Apache web server was.
Let's start by doing some recon of the Tomcat server using the various HTTP scanners in Metasploit.
Running the HTTP dir scanner module turns up some goodies:
These turn up some interesting pages that can potentially be bypassed:
The recon we do feeds into the choice of Metasploit modules that we make. First, we have a login page - this provides us with a way to brute-force login credentials. Second, we have a WebDAV interface, and a potential avenue for uploading a PHP shell. Third, the server works much like the Apache server, and is susceptible to denial of service attacks.
Login Credentials
We can do a comprehensive search for all Tomcat-related modules in metasploit:
We will focus on three modules:
Specifically, to obtain login credentials, we'll focus on tomcat_mgr_login.
tomcat mgr login
This module is, obviously, for logging into Tomcat.
Here is info on this module from the Rapid7 website: https://www.rapid7.com/db/modules/auxiliary/scanner/http/tomcat_mgr_login
Printing out the various options, it looks like a brute force method:
We'll definitely want to try blank passwords. Let's set some options:
Now fire it up:
Success! The username/password tomcat/tomcat will get us access to the server.
Uploading Java Executable with Metasploit
Just as obtaining a remote shell on the web server with Apache required uploading and executing a PHP script (see Metasploitable/Apache/DAV), obtaining a remote shell on the web server will require uploading and executing a file - but for Tomcat, the executable must be a JSP (JavaServer Pages) application.
Automated Metasploit File Upload
This is contained in the tomcat_mgr_upload module:
Set Metasploit Options
Set some options for this exploit. We'll use the credentials we already found.
The TARGETURIvariable should be left to the default, manager/ - not set to admin.
Additionally, we'll need to set the target architecture:
Run the Exploit (Failure)
Now we are ready to run:
Does not work. Not sure why.
After running the above exploit, I can log into the management page and see the WAR is successfully being uploaded by Metasploit, and that the module is active and running.
Can configure the correct path to the Tomcat manager (which is /manager).
(Note: many admins will disable these Tomcat modules or change the name of directories.)
Run the Exploit (Worked)
I set this aside for a day, and found another workaround (covered below). But then, later, the exploit worked as intended.
Houston, We Have A Meterpreter Shell
Now we have a meterpreter shell! Over and on to Meterpreter.
Uploading Java Executable Manually
For some reason, the metasploit automated payload deployment had some problems. However, we can still exploit this server manually.
The management web interface gives us a place to upload WAR files, and a way to execute them manually.
We can use Metasploit to craft a WAR file with the payload, then manually upload and execute it.
Craft WAR Payload
Now we upload the runme.war file, and set it running on the Tomcat server:
Note that this does NOT execute the payload yet!!!
To execute the payload and run the actual war file, we will need to visit the page http://10.0.0.27:8180/runme/. However, this will try and connect to our command-and-control server on port 4444, and we need to be listening for the incoming connection.
We'll use netcat to receive the incoming shell once the WAR file is executed.
Netcat Listener
Now we set netcat listening on port 4444, the port we hard-coded into our payload:
Now, netcat will listen for the incoming connection, so you're ready to execute your payload.
Once the runme.war module is enabled through the Tomcat server, visit the applet in your browser:
Apache Tomcat Download
You'll see the incoming TCP connection in netcat.
Houston, We Have a Shell
Congrats - we've got ourselves a shell!
The shell is nothing fancy, but it lets us do some things on the filesystem.
We are the tomcat 5.5 user:
Here I list the contents of the root directory:
Note that you are not root so you cannot modify files that you don't own. Same goes for trying to access SSH keys - if they're read-only for that user, you won't be able to see them.
You can also dump the contents of the startup scripts:
You could modify one of these services (or add a new one) to open a netcat shell. Need some additional practice with these netcat shells. It's possible to use a text editor like vi, but also very clunky.
It should be a lot easier to utilize an open reverse TCP connection to transfer files with netcat.
Clean Up
Remove the runme war file by going back to http://10.0.0.27:8180/manager/html and clicking 'Undeploy'.
Apache Tomcat is the leading Java application server by market share and the world's most widely used web application server overall. Currently at version 8, the popular web server has not been without its security flaws, perhaps most famously publicized in this incident of aircraft hacking by security researcher Chris Roberts earlier this year. However, hardening Tomcat's default configuration is just plain good security sense—even if you don't plan on using it on your plane's network. The following are 15 way to secure Apache Tomcat 8, out-of-the-box.
1. Don't run Tomcat as the root user
This line of advice applies to most web server platforms. Web-related services should not be run by user accounts with a high level of administrative access. In Tomcat's case, a user with the minimum necessary OS permissions should be created exclusively to run the Tomcat process.
2. Remove any default sample or test web applications
Most web server platforms also provide a set of sample or test web application for demo and learning purposes. These applications have been known to harbor vulnerabilities, and should be removed if not in use. Tomcat's examples web application is an application that should be removed to prevent exploitation.
3. Put Tomcat's shutdown procedure on lockdown
This prevents malicious actors from shutting down Tomcat's web services. Either disable the shutdown port by setting the port attribute in the server.xml file to -1. If the port must be kept open, be sure to configure a strong password for shutdown.
4. Disable support for TRACE requests
Though useful for debugging, enabling allowTrace can expose some browsers to an cross-site scripting XSS attack. This can be mitigated by disabling allowTrace in the server.xml file.
5. Disable sending of the X-Powered-By HTTP header
If enabled, Tomcat will send information such as the Servlet and JSP specification versions and the full Tomcat version, among others. This gives attackers a workable starting point to craft an attack. To prevent this information leakage, disable the xpoweredBy attribute in the server.xml file.
6. Disable SSLv3 to prevent POODLE attacks
POODLE is a SSL v3 protocol vulnerability discovered in 2014. An attacker can gain access to sensitive information such as passwords and browser cookies by exploiting this vulnerability; subsequently, SSL v3 (and SSL in general) should not be included in server.xml file under the sslEnabledProtocols attribute.
7. Set the deployXML attribute to false in a hosted environment
The prevents would-be attackers from attempting to increase privileges to a web application by packaging an altered/custom context.xml. This is especially critical in hosted environments where other web applications sharing the same server resources cannot be trusted.
8. Configure and use realms judiciously
Tomcat's realms are designed differently and their limitations should be understood before use. For example, the DataSourceRealm should be used in place of the JDBCRealm, as the latter is single threaded for all authentication/authorization options and not suited for production use. The JAASRealm should also be avoided, as it is seldom used and sports an immature codebase.
9. Set Tomcat to create new facade object for each request
This can be configured by setting the org.apache.catalina.connector.RECYCLE_FACADES system property to true. By doing this, you reduce the chance of a buggy application exposing data between requests.
10. Ensure that access to resources is set to read-only
This can be done by setting readonly to true under DefaultServlet, effectively preventing clients from deleting/modifying static resources on the server and uploading new resources.
Apache Tomcat Server Download
11. Disable Tomcat from displaying directory listings
Listing the contents of directories with a large number of files can consume considerable system resources, and can therefore be used in a denial-of-service (DoS) attack. Setting listings to false under DefaultServlet mitigates this risk.
12. Enable logging of network traffic
In general, logs should generated and maintained on all levels (e.g., user access, Tomcat internals, et al), but network traffic logging is especially useful for breach assessment and forensics. To set up your Tomcat application to create logs of network traffic, use/configure the AccessLogValve component.
13. Disable automated deployment if not in use
If you're running a fully-realized CI/CD pipeline, good for you—you'll need full use of Tomcat's host components. However, if not—be sure to set all the host attributes to false (autoDeploy, deployOnStartup, and deployXML) to prevent them from being compromised by an attacker.
14. Disable or limit the Tomcat Manager Webapp
Tomcat Manager enables easy configuration and management of Tomcat instances through one web interface. Convenient, no doubt—for both authorized administrators and attackers. Alternative methods for administering Tomcat instances are therefore better, but if Tomcat Manager must be used, be sure to use its configuration options to limit your risk exposure.
15. Limit the availability of connectors
Connectors by default listen to all interfaces. For better security, they should only listen to those required by your web application and ignore the rest. This can be accomplished by setting the address attribute of the connector element.
From the description of Coyote on the Tomcat page [1], it sounds like this server will be as susceptible to denial of service attacks as the Apache web server was.
Let's start by doing some recon of the Tomcat server using the various HTTP scanners in Metasploit.
Running the HTTP dir scanner module turns up some goodies:
These turn up some interesting pages that can potentially be bypassed:
The recon we do feeds into the choice of Metasploit modules that we make. First, we have a login page - this provides us with a way to brute-force login credentials. Second, we have a WebDAV interface, and a potential avenue for uploading a PHP shell. Third, the server works much like the Apache server, and is susceptible to denial of service attacks.
Login Credentials
We can do a comprehensive search for all Tomcat-related modules in metasploit:
We will focus on three modules:
Specifically, to obtain login credentials, we'll focus on tomcat_mgr_login.
tomcat mgr login
This module is, obviously, for logging into Tomcat.
Here is info on this module from the Rapid7 website: https://www.rapid7.com/db/modules/auxiliary/scanner/http/tomcat_mgr_login
Printing out the various options, it looks like a brute force method:
We'll definitely want to try blank passwords. Let's set some options:
Now fire it up:
Success! The username/password tomcat/tomcat will get us access to the server.
Uploading Java Executable with Metasploit
Just as obtaining a remote shell on the web server with Apache required uploading and executing a PHP script (see Metasploitable/Apache/DAV), obtaining a remote shell on the web server will require uploading and executing a file - but for Tomcat, the executable must be a JSP (JavaServer Pages) application.
Automated Metasploit File Upload
This is contained in the tomcat_mgr_upload module:
Set Metasploit Options
Set some options for this exploit. We'll use the credentials we already found.
The TARGETURIvariable should be left to the default, manager/ - not set to admin.
Additionally, we'll need to set the target architecture:
Run the Exploit (Failure)
Now we are ready to run:
Does not work. Not sure why.
After running the above exploit, I can log into the management page and see the WAR is successfully being uploaded by Metasploit, and that the module is active and running.
Can configure the correct path to the Tomcat manager (which is /manager).
(Note: many admins will disable these Tomcat modules or change the name of directories.)
Run the Exploit (Worked)
I set this aside for a day, and found another workaround (covered below). But then, later, the exploit worked as intended.
Houston, We Have A Meterpreter Shell
Now we have a meterpreter shell! Over and on to Meterpreter.
Uploading Java Executable Manually
For some reason, the metasploit automated payload deployment had some problems. However, we can still exploit this server manually.
The management web interface gives us a place to upload WAR files, and a way to execute them manually.
We can use Metasploit to craft a WAR file with the payload, then manually upload and execute it.
Craft WAR Payload
Now we upload the runme.war file, and set it running on the Tomcat server:
Note that this does NOT execute the payload yet!!!
To execute the payload and run the actual war file, we will need to visit the page http://10.0.0.27:8180/runme/. However, this will try and connect to our command-and-control server on port 4444, and we need to be listening for the incoming connection.
We'll use netcat to receive the incoming shell once the WAR file is executed.
Netcat Listener
Now we set netcat listening on port 4444, the port we hard-coded into our payload:
Now, netcat will listen for the incoming connection, so you're ready to execute your payload.
Once the runme.war module is enabled through the Tomcat server, visit the applet in your browser:
Apache Tomcat Download
You'll see the incoming TCP connection in netcat.
Houston, We Have a Shell
Congrats - we've got ourselves a shell!
The shell is nothing fancy, but it lets us do some things on the filesystem.
We are the tomcat 5.5 user:
Here I list the contents of the root directory:
Note that you are not root so you cannot modify files that you don't own. Same goes for trying to access SSH keys - if they're read-only for that user, you won't be able to see them.
You can also dump the contents of the startup scripts:
You could modify one of these services (or add a new one) to open a netcat shell. Need some additional practice with these netcat shells. It's possible to use a text editor like vi, but also very clunky.
It should be a lot easier to utilize an open reverse TCP connection to transfer files with netcat.
Clean Up
Remove the runme war file by going back to http://10.0.0.27:8180/manager/html and clicking 'Undeploy'.
Apache Tomcat is the leading Java application server by market share and the world's most widely used web application server overall. Currently at version 8, the popular web server has not been without its security flaws, perhaps most famously publicized in this incident of aircraft hacking by security researcher Chris Roberts earlier this year. However, hardening Tomcat's default configuration is just plain good security sense—even if you don't plan on using it on your plane's network. The following are 15 way to secure Apache Tomcat 8, out-of-the-box.
1. Don't run Tomcat as the root user
This line of advice applies to most web server platforms. Web-related services should not be run by user accounts with a high level of administrative access. In Tomcat's case, a user with the minimum necessary OS permissions should be created exclusively to run the Tomcat process.
2. Remove any default sample or test web applications
Most web server platforms also provide a set of sample or test web application for demo and learning purposes. These applications have been known to harbor vulnerabilities, and should be removed if not in use. Tomcat's examples web application is an application that should be removed to prevent exploitation.
3. Put Tomcat's shutdown procedure on lockdown
This prevents malicious actors from shutting down Tomcat's web services. Either disable the shutdown port by setting the port attribute in the server.xml file to -1. If the port must be kept open, be sure to configure a strong password for shutdown.
4. Disable support for TRACE requests
Though useful for debugging, enabling allowTrace can expose some browsers to an cross-site scripting XSS attack. This can be mitigated by disabling allowTrace in the server.xml file.
5. Disable sending of the X-Powered-By HTTP header
If enabled, Tomcat will send information such as the Servlet and JSP specification versions and the full Tomcat version, among others. This gives attackers a workable starting point to craft an attack. To prevent this information leakage, disable the xpoweredBy attribute in the server.xml file.
6. Disable SSLv3 to prevent POODLE attacks
POODLE is a SSL v3 protocol vulnerability discovered in 2014. An attacker can gain access to sensitive information such as passwords and browser cookies by exploiting this vulnerability; subsequently, SSL v3 (and SSL in general) should not be included in server.xml file under the sslEnabledProtocols attribute.
7. Set the deployXML attribute to false in a hosted environment
The prevents would-be attackers from attempting to increase privileges to a web application by packaging an altered/custom context.xml. This is especially critical in hosted environments where other web applications sharing the same server resources cannot be trusted.
8. Configure and use realms judiciously
Tomcat's realms are designed differently and their limitations should be understood before use. For example, the DataSourceRealm should be used in place of the JDBCRealm, as the latter is single threaded for all authentication/authorization options and not suited for production use. The JAASRealm should also be avoided, as it is seldom used and sports an immature codebase.
9. Set Tomcat to create new facade object for each request
This can be configured by setting the org.apache.catalina.connector.RECYCLE_FACADES system property to true. By doing this, you reduce the chance of a buggy application exposing data between requests.
10. Ensure that access to resources is set to read-only
This can be done by setting readonly to true under DefaultServlet, effectively preventing clients from deleting/modifying static resources on the server and uploading new resources.
Apache Tomcat Server Download
11. Disable Tomcat from displaying directory listings
Listing the contents of directories with a large number of files can consume considerable system resources, and can therefore be used in a denial-of-service (DoS) attack. Setting listings to false under DefaultServlet mitigates this risk.
12. Enable logging of network traffic
In general, logs should generated and maintained on all levels (e.g., user access, Tomcat internals, et al), but network traffic logging is especially useful for breach assessment and forensics. To set up your Tomcat application to create logs of network traffic, use/configure the AccessLogValve component.
13. Disable automated deployment if not in use
If you're running a fully-realized CI/CD pipeline, good for you—you'll need full use of Tomcat's host components. However, if not—be sure to set all the host attributes to false (autoDeploy, deployOnStartup, and deployXML) to prevent them from being compromised by an attacker.
14. Disable or limit the Tomcat Manager Webapp
Tomcat Manager enables easy configuration and management of Tomcat instances through one web interface. Convenient, no doubt—for both authorized administrators and attackers. Alternative methods for administering Tomcat instances are therefore better, but if Tomcat Manager must be used, be sure to use its configuration options to limit your risk exposure.
15. Limit the availability of connectors
Connectors by default listen to all interfaces. For better security, they should only listen to those required by your web application and ignore the rest. This can be accomplished by setting the address attribute of the connector element.
In short, Apache Tomcat's popularity invariably means that its vulnerabilities and exploits are well known by both security professionals and malicious actors alike. Out-of-the-box security is never sufficient for protecting against today's cyber threats, and proper hardening of Tomcat is especially critical given the server platform's ubiquity. Looking for a way to perform these hardening checks and more, automatically—with just a few mouse clicks? Check out ScriptRock's platform for vulnerability detection and security monitoring. It's free for up to 10 servers, so try it today on us.
Sources
