Understanding & Identifying Insecure Deserialization Vulnerabilities

This post explains the nitty-gritty of Insecure Deserialization Vulnerabilities. We will be covering basic understanding and identification., Insecure Deserialization- Vulnerability lies on the 8th spot in OWASP Top 10 Vulnerabilities-2017. It is said to be the most difficult to understand Vulnerability in OWASP Top 10.

Insecure Deserialization also was the common question that I came across frequently, in my Interviews, for InfoSec Profiles. There’s definitely a hype for this Vulnerability & if you are appearing for an interview in InfoSec, keep this in your must-to-know-list. So, now let’s get started.

What’s the root cause behind the Vulnerability?

Simple Words: The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.

When developers place no restrictions on “gadget chains,” or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

What is Serialization?

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage or to send as part of communications.

Serialization-Deserialization Process

What is Deserialization?

Deserialization is the reverse of that process, taking data structured from some format, and rebuilding it into an object. The most popular data format for serializing data is JSON and XML.

Serialization may be used in applications for:
1. Remote- and inter-process communication (RPC/IPC)
2. Wire protocols, web services, message brokers
3. Caching/Persistence
4. Databases, cache servers, file systems
5. HTTP cookies, HTML form parameters, API authentication tokens

Identifying- Is your Application Vulnerable?

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:

1. 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.
2. Typical data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.

Identifying Insecure Deserialization, at times, involves, White-Box as well as Black-Box testing.

Example:

1. Let’s take an example of an access-control-related attack, & break it down to scratch for further understanding:

Say, a PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other states:

Regular User Cookie:
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:

Admin’s Super Cookie:
a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;
i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960";}

& if the above-modified object is deserialized by the application, the attacker could elevate to “admin”. Thus, bypassing the Access-Control, due to a Vulnerable PHP object serialization.

Identifying Insecure Deserialization in known Affected Programming Languages:

PHP, Python, Java, .Net: WhiteBox & BlackBox testing:

1. For PHP:

Check the use of unserialize() function and review how the external parameters are accepted.

2. For Python:

The following API in Python will be vulnerable to serialization attacks. Search code for the pattern below.

1. The uses of pickle/c_pickle/_pickle with load/loads:

import pickle
data = “”” cos.system(S’dir’)tR. “””
pickle.loads(data)

2. Uses of PyYAML with load:

import yaml
document = “!!python/object/apply:os.system [‘ipconfig’]”
print(yaml.load(document))

3. Uses of jsonpickle with encode or store methods.

In BlackBox Review-

If the traffic data contains the symbol dot . at the end, it's very likely that the data was sent in serialization.

3. For Java:

Be aware of the following Java API uses for potential serialization vulnerability.

1. XMLdecoder with external user-defined parameters

2. XStream with fromXML method (XStream version <= v1.46 is vulnerable to the serialization issue)

3. ObjectInputStream with readObject

4. Uses of readObject, readObjectNodData, readResolve or readExternal

5. ObjectInputStream.readUnshared

6. Serializable

In BlackBox Review-

If the captured traffic data include the following patterns may suggest that the data was sent in Java serialization streams

• AC ED 00 05 in Hex
• rO0 in Base64
• Content-type header of an HTTP response set to application/x-java-serialized-object

4. For .Net CSharp

Search the source code for the following terms:

1. TypeNameHandling
2. JavaScriptTypeResolver

Look for any serializers where the type is set by a user-controlled variable.

In Black-Box Testing-

Search for the following base64 encoded content that starts with:

AAEAAAD/////

Search for content with the following text:

1. TypeObject
2. $type:

Detection Tools:

Burp Suite Extensions, that could ease the identification of Deserialization Vulnerabilities: JavaSerialKiller, Java Deserialization Scanner, Burp-ysoserial, SuperSerial, SuperSerial-Active.

Mitigation: Only Deserialize Signed Data

If the application knows before deserialization which messages will need to be processed, they could sign them as part of the serialization process. The application could then choose not to deserialize any message which didn’t have an authenticated signature.

Practice Exploitation:

Insecure deserialization | Web Security Academy

Reference:

Deserialization — OWASP Cheat Sheet Series