Recently an analysis of Foxglove Security on a vulnerability on Java Deserialization disclosed in January by frohoff and gebl (http://frohoff.github.io/appseccali-marshalling-pickles/) has highlighted a very dangerous issue in Java world. frohoff and gebl discover a very serious vulnerability in Java deserialition and pulished a tool, ysoserial (https://github.com/frohoff/ysoserial), that generate payloads for exploiting the Java Deserialization issue when the classes of one of the following library are loaded in the Java environment:
- Apache Commons Collections 3 (up to 3.2.1)
- Apache Commons Collections 4 (up to 4.4.0)
- Spring (up to 4.2.2)
- Groovy (up to 2.4.3)
While it may seems that the problem reside in the libraries, it is not. The real problem is that Java default deserialization methods deserialize every supplied serialized object, without doing any check on it. To make this issue so serious it is enough to add that the deserialization process can execute Java code defined in the class of the serialized object. The reason why the four libraries shown before are considered vulnerable (but they aren’t) is that they define some objects that can invoke custom Java methods in the deserialization process.
Therefore, to exploit this issue it is sufficient an entry point that processes serialized objects and one of library loaded in the Java environment that allow execute custom code in the deserialization process. But the real problem, as said before, are not the libraries, but the deserialization methods of Java, that deserialize (and eventually execute Java code) every object supplied without doing any check on it.
I have developed a plugin for Burp Suite that does some active checks to find deserialization vulnerabilities on Apache Commons Collections 3, Apache Commons Collections 4 and Spring. For the scanner I have used some custom payloads generated with a modified version of ysoserial (https://github.com/federicodotta/ysoserial branch “with-sleep-payloads”). The modified payloads use a synchronous Java sleep function. As a matter of fact, in my opinion, this is the best way for detect the vulnerability in an automated way. ysoserial original payloads execute commands on the system but there is no way to see the output of the executed commands. With a sleep synchronous payload, on the contrary, the detection is easy and no modification are done on the target system.
The plugin can be downloaded in the “Releases” section of the following repository (and maybe in the future in the BAppStore of Burp Suite):
The plugin checks for serialized Java object in raw format or encoded in Base64 and reports active and passive issues. The passive issues are only informational and are reported when a serialized object is found in a request. The active scan executes the payloads if and only if it found any serialized object in the body or in an insertion point. Otherwise, no additional requests are done, in order to avoid to execute a lot of useless requests to the applications that do not make use of serialized java objects.