Recently a new remote code execution vulnerability was disclosed for Apache Tomcat. Apache Tomcat is prone to by a Java deserialization vulnerability. However successful exploitation of this vulnerability requires the attacker to be able to upload an arbitrary file onto the server. This issue was assigned under CVE-2020-9484.
There are number of prerequisites for this vulnerability to be exploited.
- The PersistentManager should be enabled and it should be using FileStore.
- The attacker shoould be able to upload a file with arbitrary content & has control over the filename and knows the location where it is uploaded.
- There must be some available gadgets in the dependencies under tomcat/lib or WEB-INF/lib
Tomcat Session Management
Tomcat uses the keyword Manager to describe about the component that does session management. Sessions preserve state between client requests, and there are multiple decisions to be made about how to do that.
Tomcat has two different implementations:
org.apache.catalina.session.StandardManager (default) keeps sessions in memory. If tomcat is closed, it then stores the sessions in a serialized object on disk.
org.apache.catalina.session.PersistentManager does the same with additional functions like swapping out idle sessions. If any session has been idle for x seconds, it would be swapped out to disk. which is a way to reduce memory usage.You can even specify where and how you want swapped sessions to be stored as described below.
- FileStore: specifies directory on disk, where each swapped session will get stored as a file with the name based on their session ID.
- JDBCStore: specifies table in database, where each swapped session will be stored as individual row.
- Apache Tomcat 10.x series prior to 10.0.0-M5
- Apache Tomcat 9.x series prior to 9.0.35
- Apache Tomcat 8.x series prior to 8.5.55
- Apache Tomcat 7.x series prior to 7.0.104
At Qualys Labs, we’ve tried to reproduce the issue, reported for CVE-2020-9484. We’ve used a publicly available PoC on github to exploit the available docker image.
Use the ysoserial tool on github to generate the gadget malicious serialization data that commons-collections4
java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections2 "touch /tmp/rce" > /usr/local/tomact/groovy.session
When Tomcat receives a HTTP request with a JSESSIONID cookie, it asks the Manager to check if the session with session ID “../../../../../../usr/local/tomact/groovy” exists and then it checks whether that session is present in memory, if not then it checks whether the session is present on disk. It will check at location directory + sessionid + “.session”, which becomes “./session/../../../../../../usr/local/tomact/groovy.session. file exists.
If file exists then deserializes it and parses the session information from it.
Exploit Source: https://github.com/masahiro331/CVE-2020-9484
From the above image line marked in red shows PersistentManager tries to load the session from the FileStore. The yellow line then shows that it tries to deserialize the object and the error is thrown after deserialization succeeded but when it tried to interpret the object as a session,the malicious code already get executed at that point and file rce got created inside /tmp directory.
Apache Tomcat has officially released their official Advisory to patch the vulnerability. Customers are requested to update their Apache Tomcat versions.
Qualys customers can scan their network with QID(s)#13785,372811,173498,173497,177828,177823,173490,173489 to detect vulnerable assets.Please continue to follow on Qualys Threat Protection for more coverage on these vulnerabilities.
References and Sources: