Code Injection During Deserialization

ID

java.code_injection_deserialization

Severity

critical

Resource

Injection

Language

Java

Tags

CWE:502, NIST.SP.800-53, OWASP:2021:A8, PCI-DSS:6.5.1

Description

Improper deserialization of untrusted data, possibly allowing code injection attacks.

Deserialization vulnerabilities arise when an application deserializes user-controlled data without proper validation, potentially allowing attackers to instantiate unexpected objects or execute crafted functions leading to arbitrary code execution or system exploits.

Rationale

After detecting the vulnerable site, attackers typically craft a payload that is serialized and sent to the application. If the application deserializes this payload without validation, attackers can modify the expected data structure to escalate privileges or perform unwanted actions.

In the worst case, the attackers inject an object of an unexpected type, triggering chosen code execution. This could be used to exfiltrate internal server’s data, install malware e.g. to install and persist crypto-miners, or run a reverse shell.

The Java serialization mechanism provides a way to convert objects into a byte stream, which can later be converted back into a copy of the object. When dealing with untrusted input for deserialization, attackers can craft malicious object streams that, upon deserialization, invoke code paths within the application or libraries loaded into the application environment, typically leading to code injection exploits.

Here is an example of insecure Java deserialization:

import java.io.*;

public class DeserializationExample {
    public static void main(String[] args) {
        byte[] input = receiveInput();  // Assume this comes from an untrusted source

        try (ObjectInputStream objectInputStream = new ObjectInputStream(new ByteArrayInputStream(input))) {
            Object obj = objectInputStream.readObject();  // Unsafe deserialization
        } catch (IOException | ClassNotFoundException e) {
            e.printStackTrace();
        }
    }

    private static byte[] receiveInput() {
        // This method should accept input over a network or from a file
        return new byte[]{};
    }
}

This example demonstrates unsafe deserialization. If input is maliciously crafted, it can potentially execute harmful code or instigate other vulnerabilities in the application.

Remediation

If possible, do not deserialize content to objects when the source is not fully trusted.

Mitigating deserialization vulnerabilities involves several key practices:

  1. Avoid Deserialization of Untrusted Input: The most secure approach is to avoid deserializing any untrusted data outright. If deserialization is necessary, consider other safe data formats such as JSON or XML with strict schema validation.

  2. Use Secure Libraries: Employ libraries or frameworks that provide secure deserialization mechanisms.

  3. Validation and Whitelisting: Implement strict validation. Use a whitelist approach where only the expected, permitted, and safe classes are allowed to be deserialized.

Configuration

The detector has the following configurable parameters:

  • sources, that indicates the source kinds to check.

  • neutralizations, that indicates the neutralization kinds to check.

Unless you need to change the default behavior, you typically do not need to configure this detector.

References