Moderate
CVE-2020-9484 — PersistentManager Java deserialization vulnerability
Add Reference
Description
URL
Type
CVE-2020-9484 — PersistentManager Java deserialization vulnerability
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Description
When using 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 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter=“null” (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed.
Add Assessment
Ratings
-
Attacker ValueLow
-
ExploitabilityMedium
Technical Analysis
This attack can have high impact (RCE), but the conditions that need to be met make the likelihood of exploitation low.
- PersistentManager needs to be enabled manually by the tomcat administrator. This is likely to happen only on websites with high traffic loads (but not too high, as it will be more likely that a JDBC Store is used instead of a File Store)
- The attacker has to find a separate file upload vulnerability to place the malicious serialized file on the server.
- There have to be libraries on the classpath which are vulnerable to be exploited by a Java deserialization attack (e.g. gadgets).
However, a large range of versions of tomcat are affected.
More info in this article: https://www.redtimmy.com/java-hacking/apache-tomcat-rce-by-deserialization-cve-2020-9484-write-up-and-exploit/
Ratings
-
Attacker ValueMedium
-
ExploitabilityLow
Technical Analysis
@cblack-r7 and I looked at this a couple weeks ago, specifically https://seclists.org/oss-sec/2020/q2/136 and https://github.com/IdealDreamLast/CVE-2020-9484. I did a double take because I thought it included a file write. Not so. There are a handful of prerequisites that mitigate the impact of this vulnerability.
If the stars align, this could be valuable, since Tomcat is everywhere. But I don’t think it’s worth writing an exploit for this, beyond a PoC, since exploitation is so niche. @redtimmy’s writeup is most excellent. Go read that.
CVSS V3 Severity and Metrics
General Information
Products
- Apache Tomcat
References
Advisory
Miscellaneous
Additional Info
Technical Analysis
Report as Exploited in the Wild
What do we mean by "exploited in the wild"?
By selecting this, you are verifying to the AttackerKB community that either you, or a reputable source (example: a security vendor or researcher), has observed an active attempt by attackers, or IOCs related, to exploit this vulnerability outside of a research environment.
A vulnerability should also be considered "exploited in the wild" if there is a publicly available PoC or exploit (example: in an exploitation framework like Metasploit).