Moderate
CVE-2020-9484 — PersistentManager Java deserialization vulnerability
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
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
Topic Tags
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/
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
-
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Products
- Apache Tomcat
References
Advisory
Exploit
A PoC added here by the AKB Worker must have at least 2 GitHub stars.
Miscellaneous
Additional Info
Technical Analysis
Report as Emergent Threat Response
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below: