cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Gal_Goldshtein
F5 Employee
F5 Employee

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.
0EM1T000002JKPx.png

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.

0EM1T000002JKPy.png

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.
0EM1T000002JKPz.png

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.

0EM1T000002JKQ0.png

Figure 4: Exploitation attempt blocked with attack signature 200003440

Further reading

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

 
 
Version history
Last update:
‎17-Nov-2020 15:46
Updated by:
Contributors