XStream Insecure Deserialization Remote Code Execution (CVE-2020-26217)

Recently, a new Remote Code Execution vulnerability in XStream library was discovered.

XStream is a popular Java based XML parsing library which supports converting XML strings into Java objects and vice versa.

As we saw in previous cases of “Insecure Deserialization” (OWASP TOP 10 A8), XML/JSON parsers are high profile target for this type of vulnerability as they are converting (deserializing) text received over the wire into Java objects.

XStream in its default configuration has a built-in mechanism that intends to prevent instantiation of dangerous Java types. Before the vulnerability was patched, we can see that XStream defines three groups of types that should be rejected by the XML parser:

1. "TypeHierarchyPermission" - Objects of type "java.lang.Exception" or types that inherit from it.
2. "RegExpTypePermission" – Objects of types that match the following patterns:
3. *\$LazyIterator
4. javax\.crypto\..*
5. "ExplicitTypePermission" - Before the patch contained only the "java.beans.EventHandler" type.

Figure 1: XStream built-in security mechanism on vulnerable version

Above three groups are attempting to stop the instantiation of types that were found to be able to execute arbitrary code, also known as “gadgets” in hacker’s jargon. Meaning if an attacker will send to a server an XML containing one of those class types, while “reading” the XML, the server will unwillingly execute attacker’s code.

As we can see this security mechanism of XStream does not cover the "javax.imageio.ImageIO$ContainsFilter" type, which is ironically one of the already known dangerous types in Java for couple of years. This “gadget” was also used in this vulnerability proof of concept exploit.

The vulnerability was patched by expanding the "ExplicitTypePermission" group to contain both the "javax.imageio.ImageIO$ContainsFilter" and the "java.lang.ProcessBuilder" types.

Figure 2: "ExplicitTypePermission" expanded to contain the dangerous Java types used in the PoC exploit

 

Mitigation with Advanced WAF 

Advanced WAF customers under any supported version are already protected against this vulnerability. The Proof of Concept exploit of the vulnerability is detected by existing Java code injection signatures which identifies the dangerous “gadget” used in this CVE. We have updated the references of signature id 200004407 to mention this CVE.

Figure 3: Exploitation attempt blocked with attack signature 200004407

 

It is worth mentioning that this proof of concept exploit is blocked by tens of other existing Java code injection signatures, like a signature which detects the attempt to create a malicious process.

Figure 4: Exploitation attempt blocked with attack signature 200003440

Further reading

https://x-stream.github.io/CVE-2020-26217.html