Introduction to Deserialization Attacks

---

Introduction

As was stated in the previous section, deserialization is the reverse action to serialization, specifically taking in serialized data and reconstructing the original object in memory.

If an application ever deserializes user-controlled data, then there is a possibility for a deserialization attack to occur. An attack would involve taking serialized data generated by the application and modifying it for our benefit or perhaps generating and supplying our own serialized data.

---

History

Deserialization has been known as an attack vector since 2011, but it only went viral in 2016 with the Java Deserialization Apocalypse. This was the result of a talk delivered in 2015, in which security researchers @frohoff and @gebl explained deserialization attacks in great detail and released the infamous tool for generating Java deserialization payloads named ysoserial.

Nowadays, insecure deserialization features in the OWASP Top 10 under the A08:2021-Software and Data Integrity Failures category and many CVEs are published each year regarding this topic.

---

Attacks

Throughout this module, we will cover two primary deserialization attacks:

• Object Injection
• Remote Code Execution

Object Injection means modifying the serialized data so that the server will receive unintended information upon deserialization. For example, imagine a serialized object containing a user's role on the website. If we had control of this object, we could modify it so that when the server deserializes the object, it will instead say we have an administrative role.

Remote Code Execution is self-explanatory: in this attack, we supply a serialized payload which results in command execution upon being deserialized on the server side.

---

Identifying Serialization

White-Box

When we have access to the source code, we want to look for specific function calls to identify possible deserialization vulnerabilities quickly. These functions include (but are certainly not limited to):

• unserialize() - PHP
• pickle.loads() - Python Pickle
• jsonpickle.decode() - Python JSONPickle
• yaml.load() - Python PyYAML / ruamel.yaml
• readObject() - Java
• Deserialize() - C# / .NET
• Marshal.load() - Ruby

Black-Box

If we do not have access to the source code, it is still easy to identify serialized data due to the distinct characteristics in serialized data:

• If it looks like: a:4:{i:0;s:4:"Test";i:1;s:4:"Data";i:2;a:1:{i:0;i:4;}i:3;s:7:"ACADEMY";} - PHP
• If it looks like: (lp0\nS'Test'\np1\naS'Data'\np2\na(lp3\nI4\naaS'ACADEMY'\np4\na. - Pickle Protocol 0, default for Python 2.x
• Bytes starting with 80 01 (Hex) and ending with . - Pickle Protocol 1, Python 2.x
• Bytes starting with 80 02 (Hex) and ending with . - Pickle Protocol 2, Python 2.3+
• Bytes starting with 80 03 (Hex) and ending with . - Pickle Protocol 3, default for Python 3.0-3.7
• Bytes starting with 80 04 95 (Hex) and ending with . - Pickle Protocol 4, default for Python 3.8+
• Bytes starting with 80 05 95 (Hex) and ending with . - Pickle Protocol 5, Python 3.x
• ["Test", "Data", [4], "ACADEMY"] - JSONPickle, Python 2.7 / 3.6+
• - Test\n- Data\n- - 4\n- ACADEMY\n - PyYAML / ruamel.yaml, Python 3.6+
• Bytes starting with AC ED 00 05 73 72 (Hex) or rO0ABXNy (Base64) - Java
• Bytes starting with 00 01 00 00 00 ff ff ff ff (Hex) or AAEAAAD///// (Base64) - C# / .NET
• Bytes starting with 04 08 (Hex) - Ruby

Some tools have been developed to detect serialized data automatically. For example Freddy is an extension for BurpSuite which aids with the detection and exploitation of Java/.NET serialization.

---

Onwards

Now that we've covered serialization and deserialization attacks at a high level let's dive deep into exploiting both PHP and Python deserialization vulnerabilities.