These days I have been practicing with Burp Suite Academy and I wanted to write a post about some of the vulnerabilities they have to practice. That is a very good platform if you want to learn about web vulnerabilities and exploitation. Moreover, they offer a certification about their software "Burp Suite" which is a very good tool and well know for web hacking in the community.
In this post I am going to focus in Java deserialization vulnerability and how to detect and exploit this vulnerability.
Serialization is the process to convert a object in a data structure as a byte stream that can be stored on a disk or sent by a network. The inverse process, deserialization is the process of convert a data structure in a object. E.g. Receiving a byte stream encoded with base64, decoding it in the server and converting it into a object from the byte stream with the deserialization.
The vulnerability of Java deserialization appears when the deserialization is done in a insecure way and user can control the data. This allow to an attacker modify the serialized object to manipulate the web application. Even it is possible to change the object class by other different which could reach in a RCE.
Most of times when the web application receives an unexpected object launch an exception, however the code could already have run. E.g. Web application run an exception or internal error but you receive a connection from the server.
Burp suite can detect it automatically like shows next image, if not, it is easy to detect looking following strings in the cookie, parameters of any other HTTP headers.
- rO0 in Base64
- "H4sIAAAAAAAAAJ" when gzip(base64)
- Content-type = "application/x-java-serialized-object"
In the case we have taken as example (from Burp Suite labs). It is possible to see the serialized object in the red square:
To exploit this vulnerability directly from Burp Suite, we can use the Burp Extension called Java Deserialization Scanner. This extension allow us to detect and exploit these vulnerabilities using the tool ysoserial
After the configuration of the BApp setting the ysoserial path, we can send from Proxy http history the request that contains the serialized object to the Java Deserialization Scanner:
As the cookie encode use the following encoding: url_encoding(base64(serialized object)), in Java Deserialization scanner, after set the insertion point, we need to set the enconding that the application is expecting.
And depending of the technologies that is using the web application we need to set one of them. The list is in ysoserial Github, in this case we use:
And as payload a curl <URL of Burp collaborator>
If one of them works, there is the exploit...
In this case we can observer that we got the connection using CommonCollections2, so we have verified that the curl is running. So, now we have a RCE through the Java deserialization and exfiltrating the output via curl.