Understanding Insecure Deserialisation
By Pankaj Rane - Oct 06, 2018
Three new risks were added last year in OWASP Top 10 2017: XML External Entities (XXE), Insecure Deserialization, and Insufficient Logging and Monitoring.
This time let's talk about insecure deserialization attack which is listed as Top 8 attack in OWASP 2017.
How an attacker makes use of serialization and deserialization process to conduct attack on the web application.
So, before we perform the attack lets understand what serialization and deserialization in programming languages is and how could this be a problem in terms of security risks.
Process of converting an object into a stream of bytes is called Serialization and the process of creating object from that stream of bytes is called Deserialization.
The main purpose is to save the state of an object, so that object can be created when required.
If you take untrusted user input and you don't validate that and then you allow that untrusted user input to be deserialized from byte stream back into object then an attacker could take advantage of that and throw an insert untrusted input and this process of deserialization could cause that attackers to do bad things to your web application.
For example, a web application serializes user session data to the server’s hard drive to track sessions over time.
Conversely, deserialization is the process of converting data back into an object.
With insecure deserialization, an attacker sends a serialized object to the server and uses the deserialization process to execute arbitrary code or cause a DoS.
How it works
Imagine that a web app tracks user session by serializing a unique ID and sending it to the user’s browser. When the user opens the website, this ID is deserialized on the server and automatically logs the user in if it’s valid. An attacker finds the unique ID stored in victim browser and replaces it with arbitrary code. When victim opens the website, the server deserializes the object and runs the arbitrary code.
How to detect it
Static code analysis and manual intervention is required to detect this attack. The detection of deserialization vulnerabilities is not always a simple task. You need to generate a payload with ysoserial and send it to the target application.
Don't worry there are plugins for Burp suite which can help the web application pen testers to detect and exploit this vulnerability.
You can download the Java Deserialization Scanner Plugin from here https://github.com/federicodotta/Java-Deserialization-Scanner/releases
If you want to try hands-on, you can download vulnhub machine (Temple of Doom) which is vulnerable to deserialization attack.
All apps that accept serialized objects are vulnerable. Remotely executable exploits against major middleware products:
How to Prevent It
The safest route is to avoid serialization entirely and use a pure data format such as JSON or XML.
If serialization is necessary, perform strict data type checks on the object before deserializing it.
You should also isolate the deserialization process as much as possible by running it with a low-privilege user account or separate from the rest of your application code.
In addition to the above prevention techniques WAF you could put that in front of your web application and so as a potential insecure deserialization attack is attempted at your web application then a WAF could notice that and could stop that before it ever gets to your web application.