For this, we will be getting all of our information from OWASP which can be found here.
We will start off by looking at the Threat agents & attack vectors along with the impact.
“Threat Agents/Attack Vectors: Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code.”
“Impacts: The impact of deserialization flaws cannot be overstated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible. The business impact depends on the protection needs of the application and data.”
So from the threat agents and attack vectors, we are not provided much information except that it is almost all reliant on manual testing. So let’s look at what makes an application vulnerable so we know what to look for while testing.
Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks:
- Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.
- Typical data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.
Serialization may be used in applications for:
- Remote- and inter-process communication (RPC/IPC)
- Wire protocols, web services, message brokers
- Caching/Persistence
- Databases, cache servers, file systems
- HTTP cookies, HTML form parameters, API authentication tokens
Now let’s look at the two provided scenarios to understand what it may look like.
Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.
Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:
a:4:{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”;
i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
An attacker changes the serialized object to give themselves admin privileges:
a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;
I:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}
This vulnerability is all about deserialization so to really understand it I suggest you read the cheat sheet here.