JChainz: Automatic Detection of Deserialization Vulnerabilities for the Java Language

Abstract

In the last decade, we have seen the proliferation of code-reuse attacks that rely on deserialization of untrusted data in the context of web applications. The impact of these attacks is really important since they can be used for exposing private information of the users.

In this paper, we design a tool for automatic discovery of deserialization vulnerabilities for the Java language. Our purpose is to devise an automatic methodology that use a set of program analysis techniques and is able to output a deserialization attack chain. We test our techniques against common Java libraries used in web technology. The execution of our tool on such a dataset was able to validate the attack chains for the majority of already known vulnerabilities, and it was also able to discover multiple novel chains that represent new types of attack vectors.

1 Appendix

1.1 1.1 Case Studies

By taking advantage of our tool, we discovered and exploited new chains described in the following repositories [16, 17]. Each chain is composed of two main parts, the first one from the entry point to the exit-point. In this case, the exit-point is the method.invoke method. The latter exit-point allows an attacker to access and call the entire set of methods and classes available in the java classpath. The second part of the chain is composed of a gadget. In our experiments, we attached the well-known gadgets already available in the ysoserial repository, which allowed us to run arbitrary code. The gadget can be seen as an already sequence of methods for achieving a specific operation. These chains have been discovered by the Finder, filtered by the Analyzer, then manually validated and exploited.

CommonsCollections7 The payload CommonsCollections7 [17], found with the aid of our tools, consists of the following chain:

java.util.Hashtable.readObject

java.util.Hashtable.reconstitutionPut

collections.map.AbstractMapDecorator.equals

java.util.AbstractMap.equals

collections.map.LazyMap.get

collections.functors.ChainedTransformer.transform

collections.functors.InvokerTransformer.transform

java.lang.reflect.Method.invoke

sun.reflect.DelegatingMethodAccessorImpl.invoke

sun.reflect.NativeMethodAccessorImpl.invoke

sun.reflect.NativeMethodAccessorImpl.invoke0

java.lang.Runtime.exec

The chain starts in the JDK class Hashtable, and produces an invocation of an arbitrary system command, via Runtime.exec. In order to reach this result, the chain reuses the LazyMap gadget from chain CommonsCollections5, already part of ysoserial before our work. Therefore, the novelty of CommonsCollections7 consists of the trigger made of the first five methods in the chain, up to the invocation of the gadget with entry point LazyMap.get.

While the potential exploitability of the chain was confirmed by our Analyzer, we still had to build the code for the exploit. To trigger the method sequence leading to the invocation of LazyMap.get starting from Hashtable, we built an hashtable containing two instances of the LazyMap gadget object we wanted to reuse, with the aim of triggering comparison between the two in the hashtable upon the insertion of the second. This comparison would force the call to equals on the LazyMap, which calls method get and triggers the gadget.

We discovered that inserting the same object twice in the hashtable was not sufficient, as the duplicate would be recognized right away without the need of any comparison with the objects already present in the hashtable. Therefore, we fabricated two different instances of the LazyMap, but with colliding hashes. This was possible because it is extremely easy to obtain colliding object hashes in Java, as the hashing mechanism has not been designed for security purposes and does not make use of any cryptographic hash function. In the specific case of LazyMap, the hash of the entire object is calculated from the hashes of the objects in the map. Therefore, it was sufficient for us to make the keys of the LazyMap gadgets collide. In particular, we chose colliding String objects "yy" and "zZ".

At this point, the LazyMap objects can be inserted in the Hashtable, which will be then serialized. When deserialized, the reconstruction of the hashtable via its custom readObject method will insert the two objects. The insertion of the second will trigger a comparison with the first because of the colliding hashes, starting the rest of the chain as seen above. This manual design enabled us to transform the chain found by our framework into a fully functional deserialization exploit.

CommonsCollections8. The payload CommonsCollections8 has an interesting property that differentiates it from all other previous Commons Collections payloads: its entry point (i.e. the serializable class TreeBag) is part of the library itself, while all other known chains have entry points in standard Java classes found in the JRE. The payload CommonsCollections8 [16] generates the following stacktrace:

org.apache.commons.collections4.bag.TreeBag.readObject

collections4.bag.AbstractMapBag.doReadObject

java.util.TreeMap.put

java.util.TreeMap.compare

collections4.comparators.TransformingComparator.compare

collections4.functors.InvokerTransformer.transform

java.lang.reflect.Method.invoke

sun.reflect.DelegatingMethodAccessorImpl.invoke

sun.reflect.NativeMethodAccessorImpl.invoke

sun.reflect.NativeMethodAccessorImpl.invoke0

com.sun.org.apache.xalan.(...).TemplatesImpl.newTransformer

... (TemplatesImpl gadget)

java.lang.Runtime.exec

This chain starts in the TreeBag class and leads to the execution of the Runtime.exec method, triggering the vulnerability in the Commons Collections 4.0 package. The contribution of this chain, like the previous one (Sect. 1.1), consists of spotting a new entry point.

The payload is composed by a TreeBag object built with a comparator of the type TransformingComparator and populated with a TemplatesImpl object from the ysoserial repository. During the deserialization process, the TreeBag class builds a new TreeMap object containing the attacker’s comparator and passes it to the AbstractMapBag.doReadObject method as a parameter. At this point, the put method is invoked on the map object received as parameter, triggering the compare method call on the unsafe comparator. Starting from the transform method, the following operations that lead to the execution of arbitrary code are managed by the gadget from ysoserial.