Tomcat WAR shell upload (authenticated)

Let's say we have the credentials to an Apache Tomcat instance (maybe via snooping/sniffing or from a file with sensitive information). A user can run a web application by uploading a packed WAR file to the Apache Tomcat instance. In this section, we will upload a WAR file to get a bind/reverse shell connection. Please note that the WAR shell upload requires authentication to work; otherwise, the server will respond with an HTTP 401 (Unauthorized) code:

1. To begin with, let's request the /manager/html page. The server will ask for HTTP authentication:

2. Once authenticated, the page will be redirected to /manager/status, as in the following screenshot:

3. Clicking on List Applications will list all the installed applications that are managed by this Apache Tomcat instance:

4. Scrolling down the same page, we'll find a Deploy section where we can either deploy the WAR that is on the server via the URL, or we can deploy it by uploading our own WAR file:

5. We can upload a WAR file (redteam.war) to the server from the WAR file to deploy section of the page. Clicking on the Deploy button will deploy our WAR file. In the event of a successful WAR deployment, our application will be installed on the Apache Tomcat server, which we can view from the List Applications option (as mentioned previously):

6. As you can see in the preceding screenshot, our WAR file is deployed. Now, we just need to access our JSP shell from the browser normally and pass the commands to execute as values to the parameters (shown in the following screenshot):

The same process can also be achieved using Metasploit. Using the tomcat_mgr_upload module in Metasploit, we can upload a WAR shell. Let's use this module by executing the following command in msfconsole:

use exploit/multi/http/tomcat_mgr_upload

The following screenshot shows the output of the preceding command:

As this is an authenticated mechanism, we need to provide the credentials for HTTP authentication. Let's execute this module so that Metasploit can upload the WAR file and execute the payload on the server:

As you can see in the preceding screenshot, the module was successfully authenticated with the server and uploaded a WAR file (ymRRnwH.war). Once uploaded, the module then called the JSP payload packed inside the WAR file and executed it to get a reverse meterpreter connection:

The following are the steps that meterpreter checks while executing the tomcat_mgr_upload module:

1. The Metasploit module checks whether the credentials are valid.
2. If they are valid, the module gets the value for org.apache.catalina.filters.CSRF_NONCE from the server response (the CSRF token).
3. The module then tries to upload a WAR payload through the HTTP POST method (without authentication).

4. If the preceding step fails, the module uploads the WAR file (POST/manager/html/upload) using the credentials provided to it.
5. Upon successful upload, the module requests the JSP meterpreter file from the server, resulting in an opened meterpreter connection (a reverse connection, in this case).

Note:
We have uploaded and executed the meterpreter shell to get a reverse connection. There are some cases where a reverse connection is not possible. In these instances, we can always look for bind connections or maybe tunnel the meterpreter sessions via HTTP.

Now that we know how we can upload a WAR shell to an Apache Tomcat instance and how we can exploit some of the vulnerabilities, let's move on to the next level of attacks that are performed on the Apache Tomcat instance.