Prismo Systems Jul 31, 2020 12:00:00 AM 6 min read

Analysis of CVE-2020-9484: Persistent Manager Java Deserialization Vulnerability


CVE-2020-9484 is a recently disclosed vulnerability in Apache. The vulnerability resides in how Apache Tomcat handles HTTP sessions. The first part of this post details the handling of HTTP sessions for web applications, followed by a discussion of the details and detection of the vulnerability.

Apache Tomcat HTTP session management

In Apache Tomcat HTTP sessions are created and maintained by a session manager called "Manager" Component. The Apache Tomcat Manager provides two standard ways to implement and manage sessions requested by the associated web applications - Standard Manager and Persistent Manager.

Standard Manager keeps all active HTTP sessions in memory, when a restart, shutdown, or web application reload happens, it serializes all active sessions and stores them on-disk file. Persistent Manager provides additional facility to swap idle sessions from memory by serializing and storing it into disk files. In the case of massive web application deployment, it helps to reduce memory usage. It saves the session on the disk using the session id itself; similarly, it searches the stored session information using session id.

The Standard session manager is the default session manager; the Persistent session manager must be configured and generally used by web applications serving a large number of client requests.

Exploitation Details of CVE-2020-9484

When an HTTP request comes to Apache Tomcat with session information, the Persistent Manager first searches for the session in memory. If the session is not present in the memory, it searches for the session in stored sessions on disk. If the session is found in stored sessions, it deserializes the saved session and loads it into memory.

The vulnerability resides in Persistent Manager.  An attacker can send crafted session information in the HTTP request that leads to unsafe deserialization of the attacker-controlled object. In the crafted session information, an attacker can send the path of a file controlled by the attacker and Persistent Manager component is tricked into deserializing the file which can lead to Remote Code Execution on the server. Figure 1 and Figure 2 below show authentic and malicious session information in HTTP requests, respectively.

cve-2020-9484-image3Figure 1. Authentic session information
post image
Figure 2.  Malicious session information pointing to file in the temp directory

When the Persistent session manager handles the HTTP session information, as shown in Figure 2, it eventually loads the session information from the file present at /tmp/CommonCollections7 by traversing the relative path.

Vulnerable code for CVE-2020-9484

Following is code snippet from org.apache.catalina.session.PersistentManagerBase class that loads requested HTTP session from stored sessions.


Figure 3.  Persistent Manager loading HTTP session from stored files

The loaded session gets deserialized in org.apache.catalina.session.FileStore class. It loads the content of the file into ObjectInputStream using FileInputStream(), later calling readObject() on the ObjectInputStream object.

try post image

Figure 4. FileStore class deserializing the stored session from file

Exploitation Steps

The exploitation of the vulnerability by threat actor will require the following steps to perform.

  1. Uploads a malicious serialized payload file on the server.
  2. Sends crafted session information in HTTP requests.
  3. Apache Tomcat Persistent Manager search for session file and deserialize the malicious payload file.
  4. The malicious payload executes code in the context of the Apache Tomcat server.

The exploitation of the vulnerability requires a persistent session manager configured as the default session manager. Threat actors should have permission to upload the file on the server. The exploitation of the vulnerability also requires a threat actor to know the relative file path from the Apache Tomcat folder's working directory and the libraries present on the classpath, which leads to unsafe deserialization.


Prismo’s Detection

Figure 5.0 shows the detection of insecure deserialization payload, which leads to remote code execution. By instrumenting the web application, the algorithm uses data flow analysis to trace the flow of data from methods that accept user inputs to the program execution functions. The stack trace is then used to validate if the data flow is malicious or benign, leading to vulnerability detection.


        Figure 5.  Prismo Detecting the attack as insecure deserialization


The blog details the analysis of recent discovered CVE-2020-9484 in Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103. In this blog, we further share the detection of vulnerability by instrumenting web applications. Detection of vulnerability by instrumenting application provides an inherent advantage. It not only detects the exploitation of the vulnerability but also identifies the vulnerable code path with each detected attempt of exploitation.  If the vulnerable code path gets fixed, it will reduce alerts increasing the complexity to exploit web applications.



References [1]  CVE-2020-9489,  Persistent Manager Java Deserialization Vulnerability

Prismo Systems

Prismo is the first security platform to connect fragmented data across silos, empowering enterprises to continuously expose blind spots, proactively reduce attack surface, automatically mitigate risk, and adhere to the NIST cybersecurity framework. With Prismo, enterprises transform the way they secure users, assets, and applications with an active risk-based approach that simplifies the security stack, streamlines operations, lowers costs, and dramatically reduces risk. Headquartered in Silicon Valley, Prismo is backed by Sequoia Capital.