Doh! Understanding Deserialization
So what is Insecure Deserialization?
Web applications, which we all use everyday, sometimes suffer from severe vulnerabilities. Bad actors can use these vulnerabilities to gain access to our personal or financial data.
Let's take a quick look at one major software flaw becoming more and more common: "Insecure Deserialization".
Insecure Deserialization is number #8 on the Open Web Application Security Project's Top 10 Web Application Security flaws.
Also known as 'Untrusted Deserialization', it is a vulnerability in software that arises when a program unsafely accepts and processes serialized data. Applications serialize data sets for storage, transfer and distribution purposes.
Its like when your favorite sandwhich shop turns pile sof provolone, ham, prosciuttini, cappacuolo, salami, and pepperoni into a sandwich for distribution and consumption: A Serialized-Sandwich.
When a program fails to validate the serialized data, the de-serialization process can expose other parts of the application to unintended access that may be controlled by an attacker. Like someone replacing the ham with a laxative. Now the sandwich has unintended, additional access to your digestive system.
Computer data is generally organized in data structures such as arrays, tables, trees and classes. When data structures need to be stored or transmitted to another location, such as across a network, they are serialized. Serialized objects can be structured in text such as JSON, XML or YAML, for example.
Serialized objects many times contain calls to methods which are instructions for handling various parts of the serialized data. During a successful attack, the bad actor modifies the expected serialized data to include calls to other, unexpected publicly available methods.
The hack of Equifax in 2017, which gained worldwide attention was an example of a java deserialization attack.
What developers do wrong & How Hackers exploit it:
Lets look at some recent examples of how deserialization is being exploited:
In this unsafe JAVA object deserialization, the researcher was able to execute commands on Paypal servers and access production databases. The researcher noticed a base64 value being passed to a parameter and after decoding it, realized that it was a serialized object which lacked a signature.
Failing to sign this object proved to be its doom. Based on previous research by Foxglove, hacker was able to call the class "CommonCollections1", which was in the applications “classpath”. Using the yoserial tool, hacker wrote an exploit to execute arbitrary OS commands on the web servers of manager.paypal.com.
FastJson Remote Code Execution:
To understand this deserialization attack, we have to understand 'types'. 'Types' are descriptors used to tell the deserializer what type of data its about to handle, for instance numbers, strings, etc. Types may also be more complex and custom to the application. When the 'type' can be controlled and supplied as input, this becomes dangerous.
The developers of Fastjson attempted to secure the 'type' being de-serialized through the use of a blacklist.
.NET Deserialization Attack through the Clipboard
Node.js deserialization bug for Remote Code Execution
In all three of the above examples, a tool called yoserial, was used and/or updated with signatures for other hackers to rediscover these vulnerabilities.
Detecting DeSerialization vulns during S-SDLC (Secure Software Development Life Cycle)
Typical SDLC processes attempt vulnerability discovery through tools like Dynamic Code Analysis (DAST), which will analyze an application live as its functioning, known as "runtime execution" and Static Code Analysis (SCA) which uses known signatures of "bad" operations to analyze the source code. Both of these processes struggle to identify insecure Deserialization issues. Some SCA products are able to detect “hot” calls in code, which may indicate potential Insecure Deserialization vulnerabilities, however the operation is so common that the information that SCA provides is typically ignored or considered near useless.
Tools that have a runtime visibility of the system (DAST) can only test known payloads. DASTs cannot identify undocumented vulnerabilities.
What about Active Defense?
A Wireless Application Firewall (WAFs) is a defense technology that works on the edge of an application. It creates a "walled off" perimeter. Unfortunately, this means WAFs do not typically have visibility of the application internals, and no visibility of runtime execution.
Because the WAF sits on the perimeter, it can only protect the application by applying input validation. This input validation can only be based on known signatures.
Discovering Insecure Deserialization
Ayyo Technology has the Application security experience and expertise to thoroughly anaylize your source code and live application. We can test your application for Insecure Deserialization most other publish and unpublished vulnerabilities and exploitable conditions.
Contact us for more information
For more examples and information see:
https://media.blackhat.com/bh-us-12/Briefings/Forshaw/BH_US_12_Forshaw_Are_You_My_Type_WP.pdf
https://know.bishopfox.com/research/cve-2019-18935-remote-code-execution-in-telerik-ui
Java based JSON serialization library called Fastjson:
https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html