2024 CWE Top 25 Most Dangerous Software Weaknesses: Deserialisation of Untrusted Data (CWE-502)

Deserialisation-of-Untrusted-Data-KrishnaG-CEO

2024 CWE Top 25 Most Dangerous Software Weaknesses: Deserialisation of Untrusted Data CWE-502

In the ever-evolving landscape of software development, security remains a pivotal concern. Among the numerous vulnerabilities that plague modern applications, deserialisation of untrusted data (CWE-502) is a recurring menace. It is listed in the 2024 CWE Top 25 Most Dangerous Software Weaknesses, underscoring its criticality and potential to cause catastrophic consequences if left unaddressed.

This blog post is tailored for Software Developers and Software Architects, delving deep into the mechanics, implications, and mitigation strategies for CWE-502. By the end, you’ll have a robust understanding of this vulnerability and be equipped with actionable insights to fortify your software systems.

What is Deserialisation of Untrusted Data (CWE-502)?

Deserialisation refers to the process of converting serialised data (a compact format of an object or data structure) back into its original form. While this operation is indispensable in modern software, it becomes a vulnerability when the deserialised data originates from an untrusted source.

When untrusted data is deserialised without validation, attackers can exploit the process to execute arbitrary code, manipulate application logic, or inject malicious payloads. CWE-502 encapsulates this weakness, highlighting its potential to compromise data integrity, confidentiality, and availability.

Why Does Deserialisation Pose a Risk?

  • Unverified Data Origin: Deserialising data from unverified sources opens the door to potentially malicious inputs.
  • Complexity of Object Graphs: Rich object graphs with intricate relationships are harder to validate, increasing attack surfaces.
  • Language-Specific Issues: Languages like Java, Python, and PHP have deserialisation libraries that are often targeted due to their widespread use and inherent vulnerabilities.

Real-World Impact of CWE-502

The ramifications of CWE-502 extend beyond theoretical risks, manifesting in numerous real-world cyber incidents. Here are notable examples that underscore its severity:

  1. Equifax Breach (2017): Exploitation of an Apache Struts vulnerability linked to deserialisation contributed to one of the largest data breaches in history, affecting 147 million people.
  2. Gadget Chains in Java: Attackers leveraged insecure Java deserialisation mechanisms, using gadget chains to execute arbitrary code remotely.
  3. PHP Object Injection: Exploits targeting PHP deserialisation have resulted in web application takeovers and unauthorised data access.

Real-World Cyber Incidents Involving CWE-502 (Deserialisation of Untrusted Data)

Deserialisation of untrusted data (CWE-502) has been a critical vulnerability exploited in numerous high-profile cyber incidents. Here are detailed accounts of real-world cases where CWE-502 played a central role:

1. Equifax Data Breach (2017)

Overview

Equifax, one of the largest credit reporting agencies, suffered a massive data breach in 2017, compromising the sensitive personal data of 147 million individuals.

Attack Details

  • The attackers exploited a deserialisation vulnerability in the Apache Struts 2 framework used by Equifax.
  • By sending malicious payloads to the application’s REST interface, the attackers triggered deserialisation processes that allowed them to execute arbitrary code on the server.
  • The exploit provided the attackers with access to sensitive databases.

Impact

  • Personal and financial data, including Social Security numbers, were leaked.
  • Equifax faced reputational damage and incurred fines exceeding $700 million.

Key Lessons

  • Keeping frameworks and libraries updated is crucial.
  • Conducting regular security audits and testing for vulnerabilities like CWE-502 can prevent exploitation.

2. Java Gadget Chain Exploits

Overview

Java applications, due to their reliance on deserialisation for object transfer, have been prime targets for attackers exploiting CWE-502 vulnerabilities.

Attack Details

  • Attackers leveraged gadget chains—a sequence of reusable objects in common Java libraries (like Apache Commons Collections and Java Beans) to execute malicious code.
  • The exploit typically begins with sending a crafted serialised object to an application that deserialises it without proper validation.
  • This attack was used to gain remote control over servers or steal sensitive data.

Impact

  • Thousands of Java applications globally were compromised.
  • Exploits caused significant operational disruptions in sectors such as finance, healthcare, and e-commerce.

Key Lessons

  • Avoid unsafe deserialisation libraries or add security filters to block known gadget chains.
  • Implement strict type restrictions during deserialisation.

3. PHP Object Injection in Web Applications

Overview

Web applications built on PHP have been targeted through deserialisation vulnerabilities, particularly object injection attacks.

Attack Details

  • Attackers exploit insecure PHP deserialisation to execute arbitrary commands or manipulate application data.
  • Vulnerabilities were found in popular CMS platforms like WordPress, Joomla, and Drupal due to improper handling of serialised input.

Impact

  • Several high-traffic websites experienced defacement and data breaches.
  • Some attacks resulted in database leaks containing user credentials and payment information.

Key Lessons

  • Use safer alternatives like JSON for data serialisation.
  • Validate and sanitise all input before deserialising in PHP.

4. Jenkins CI Server Exploit (2017)

Overview

Jenkins, a widely used open-source automation server, was found vulnerable to CWE-502 due to insecure Java deserialisation.

Attack Details

  • Exploits targeted the Remoting feature, allowing attackers to send crafted serialised payloads that enabled remote code execution.
  • The vulnerability affected Jenkins instances exposed to untrusted networks without authentication mechanisms.

Impact

  • Exploits led to server takeovers, allowing attackers to install malware and mine cryptocurrency.
  • Many organisations using Jenkins faced downtime and security incidents.

Key Lessons

  • Restrict access to administration interfaces and features like Remoting.
  • Apply patches immediately when vulnerabilities are disclosed.

5. PayPal Deserialisation Vulnerability (2018)

Overview

In 2018, PayPal suffered from a deserialisation vulnerability in one of its backend services.

Attack Details

  • A researcher discovered that a service endpoint accepted serialised Java objects from users.
  • The lack of proper input validation enabled potential remote code execution on the server.

Impact

  • PayPal fixed the issue before it could be exploited in the wild, thanks to its bug bounty programme.
  • This case highlights the critical role of responsible disclosure and proactive vulnerability management.

Key Lessons

  • Always validate user-provided data rigorously.
  • Implement strong bug bounty programmes to uncover hidden vulnerabilities.

6. Adobe ColdFusion Exploit (2019)

Overview

Adobe’s ColdFusion framework faced a deserialisation vulnerability that was exploited by attackers to gain unauthorised access to servers.

Attack Details

  • Attackers sent crafted payloads that manipulated the ColdFusion deserialisation process to execute arbitrary commands.
  • Many vulnerable servers were left unpatched despite Adobe’s security advisory.

Impact

  • Multiple websites hosted on ColdFusion experienced breaches, leading to data theft and malware installation.

Key Lessons

  • Apply security patches promptly.
  • Disable unused features and enforce strict access controls.

7. WebLogic Server Exploits (2019 and 2020)

Overview

Oracle’s WebLogic Server, a popular enterprise middleware product, has been repeatedly targeted due to deserialisation vulnerabilities.

Attack Details

  • Attackers leveraged vulnerabilities in the WebLogic deserialisation process to achieve remote code execution.
  • These vulnerabilities (CVE-2019-2725 and CVE-2020-14645) were exploited in the wild before patches were released.

Impact

  • Many organisations faced ransomware attacks and operational disruptions.
  • Sensitive data was stolen, causing regulatory compliance challenges.

Key Lessons

  • Isolate critical systems from untrusted networks.
  • Monitor for exploit attempts using intrusion detection systems.

8. Magento and OpenMage Exploits

Overview

Magento, a widely used e-commerce platform, and its fork OpenMage were found vulnerable to PHP deserialisation attacks.

Attack Details

  • Exploits targeted improperly secured serialised sessions or data.
  • Attackers could manipulate application logic or inject malicious code by exploiting deserialisation flaws.

Impact

  • Affected online stores experienced data theft, including customer payment details.
  • Some websites faced complete compromise, affecting business continuity.

Key Lessons

  • Use secure deserialisation mechanisms or alternative formats like JSON.
  • Regularly scan applications for deserialisation vulnerabilities.

Key Takeaways from These Incidents

  1. Patch Management: Many vulnerabilities were exploited because organisations failed to apply security patches promptly.
  2. Input Validation: A recurring theme in CWE-502 incidents is the lack of robust input validation, making it critical to validate all inputs rigorously.
  3. Safe Deserialisation Libraries: Transitioning to safer serialisation formats (e.g., JSON, XML) can mitigate deserialisation risks.
  4. Security Awareness: Organisations with strong security awareness programmes (e.g., PayPal) identified and mitigated vulnerabilities proactively.
  5. Bug Bounty Programmes: Encouraging ethical reporting of vulnerabilities helps organisations address issues before exploitation.

Conclusion

CWE-502 vulnerabilities have been the root cause of significant cyber incidents, underscoring the need for vigilance and proactive measures. By studying these real-world cases, software developers and architects can gain valuable insights into how deserialisation flaws are exploited and, more importantly, how to mitigate them effectively.

Mechanics of an Exploit

To fully comprehend CWE-502, understanding its exploitation process is crucial:

  1. Serialised Payload Creation: The attacker crafts a malicious serialised object containing a payload designed to execute specific actions when deserialised.
  2. Delivery: The payload is delivered through various channels, such as HTTP requests, file uploads, or inter-process communication.
  3. Deserialisation: The application deserialises the object without proper validation, inadvertently executing the malicious payload.
  4. Execution: Depending on the payload, the exploit can result in remote code execution (RCE), data theft, or system compromise.

Key Indicators of CWE-502 in Software

Identifying the presence of CWE-502 in your codebase involves examining the following patterns:

  • Usage of Unsafe Libraries: Libraries or frameworks with known deserialisation vulnerabilities.
  • Absence of Input Validation: Lack of robust checks on incoming data before deserialisation.
  • Dependency on Object Graphs: Heavy reliance on complex object structures that are inherently hard to secure.
  • Lack of Logging and Monitoring: Difficulty in tracing deserialisation activities within the system.

Mitigation Strategies

  1. Validate All Inputs
    • Implement rigorous input validation mechanisms to ensure that only legitimate data is processed during deserialisation.
    • Employ whitelisting approaches where feasible.
  2. Use Safe Libraries
    • Opt for deserialisation libraries with built-in security features, such as Jackson in Java or JSON.parse in JavaScript.
    • Avoid libraries with a history of vulnerabilities unless absolutely necessary.
  3. Restrict Object Types
    • Explicitly specify the object types that are permissible during deserialisation to limit the attack surface.
    • Employ “type filtering” features offered by some libraries.
  4. Isolate the Deserialisation Process
    • Execute deserialisation in a sandboxed environment to contain potential exploits.
    • Use separate processes with minimal privileges for deserialisation tasks.
  5. Implement Logging and Monitoring
    • Maintain detailed logs of deserialisation activities to detect anomalies early.
    • Integrate monitoring tools that can flag suspicious behaviour.
  6. Patch and Update Regularly
    • Stay abreast of the latest security patches and updates for deserialisation libraries and frameworks.
    • Monitor CVEs (Common Vulnerabilities and Exposures) relevant to your technology stack.

Best Practices for Software Developers and Architects

Design Phase

  • Threat Modelling: Identify potential deserialisation vulnerabilities during the architecture design phase.
  • Secure Design Principles: Adopt principles such as “least privilege” and “fail-safe defaults” to minimise risks.

Development Phase

  • Code Reviews: Incorporate secure coding practices and peer reviews to detect deserialisation flaws early.
  • Static Analysis Tools: Use tools like SonarQube or Checkmarx to automate vulnerability detection.

Testing Phase

  • Penetration Testing: Simulate deserialisation attacks to evaluate the system’s resilience.
  • Fuzz Testing: Employ fuzzers to identify unexpected behaviours in deserialisation logic.

Deployment Phase

  • Runtime Defences: Use runtime application self-protection (RASP) tools to block deserialisation exploits dynamically.
  • Incident Response Plans: Develop and test incident response plans tailored to deserialisation attacks.

Technological Insights: Tools and Techniques

Libraries with Enhanced Security

  • Jackson (Java): Supports custom deserialisers and type filtering.
  • System.Text.Json (C#): Offers safe deserialisation mechanisms with clear type constraints.
  • json.loads (Python): Use with object_hook to validate and sanitise inputs.

Advanced Security Tools

  • Burp Suite: For simulating deserialisation attacks during penetration testing.
  • YASCA: A static code analysis tool to identify insecure deserialisation.
  • OWASP ZAP: To detect and mitigate vulnerabilities in web applications.

Here are code snippets showcasing secure and insecure deserialisation practices in different programming languages. These examples highlight the right and wrong approaches to handling deserialisation.

Java

Insecure Deserialisation

import java.io.*;

public class InsecureDeserialization {

    public static void main(String[] args) {

        try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream(“data.ser”))) {

            Object obj = ois.readObject(); // No validation of object type

            System.out.println(“Deserialised object: ” + obj);

        } catch (IOException | ClassNotFoundException e) {

            e.printStackTrace();

        }

    }

}

  • Issue: This code deserialises objects directly without verifying their type or source, making it vulnerable to attacks.

Secure Deserialisation

import java.io.*;

import java.util.Base64;

public class SecureDeserialization {

    public static void main(String[] args) {

        try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream(“data.ser”))) {

            Object obj = ois.readObject();

            // Validate object type

            if (obj instanceof ExpectedClass) {

                ExpectedClass data = (ExpectedClass) obj;

                System.out.println(“Deserialised object: ” + data);

            } else {

                throw new IllegalArgumentException(“Invalid object type”);

            }

        } catch (IOException | ClassNotFoundException e) {

            e.printStackTrace();

        }

    }

}

  • Improvements:
    • Validates the type of the deserialised object.
    • Prevents deserialisation of unexpected or malicious objects.

Python

Insecure Deserialisation

import pickle

# Insecure deserialisation

data = b”malicious_payload”

untrusted_object = pickle.loads(data)  # Accepts untrusted input

print(untrusted_object)

  • Issue: Using pickle.loads on untrusted data can lead to arbitrary code execution.

Secure Deserialisation

import json

# Secure deserialisation using JSON

trusted_data = ‘{“name”: “John Doe”, “role”: “developer”}’

parsed_data = json.loads(trusted_data)  # Safer than pickle

print(parsed_data)

  • Improvements:
    • Uses JSON for deserialisation, which doesn’t execute code.
    • Validates input by relying on a safer data format.

JavaScript

Insecure Deserialisation

// Insecure deserialisation

const data = ‘{“__proto__”:{“admin”:true}}’;

const obj = JSON.parse(data); // Accepts untrusted data

console.log(obj.admin); // Exploitable due to prototype pollution

  • Issue: Directly parsing untrusted JSON can lead to prototype pollution attacks.

Secure Deserialisation

// Secure deserialisation

const safeParse = (jsonString) => {

    try {

        const parsed = JSON.parse(jsonString);

        // Validate the structure of the parsed object

        if (typeof parsed === ‘object’ && !Array.isArray(parsed)) {

            return parsed;

        } else {

            throw new Error(“Invalid data structure”);

        }

    } catch (error) {

        console.error(“Deserialisation error:”, error.message);

        return null;

    }

};

const data = ‘{“name”:”John Doe”, “role”:”developer”}’;

const obj = safeParse(data);

console.log(obj);

  • Improvements:
    • Includes validation to ensure the deserialised object is of the expected structure.
    • Prevents prototype pollution by limiting object manipulation.

C#

Insecure Deserialisation

using System;

using System.IO;

using System.Runtime.Serialization.Formatters.Binary;

class Program

{

    static void Main()

    {

        BinaryFormatter formatter = new BinaryFormatter();

        using (FileStream stream = new FileStream(“data.bin”, FileMode.Open))

        {

            object obj = formatter.Deserialize(stream); // Direct deserialisation

            Console.WriteLine(obj);

        }

    }

}

  • Issue: BinaryFormatter can deserialise any object, leading to potential remote code execution.

Secure Deserialisation

using System;

using System.IO;

using System.Text.Json;

class Program

{

    static void Main()

    {

        string jsonData = File.ReadAllText(“data.json”);

        // Secure deserialisation using System.Text.Json

        var obj = JsonSerializer.Deserialize<ExpectedClass>(jsonData);

        if (obj != null)

        {

            Console.WriteLine($”Name: {obj.Name}, Role: {obj.Role}”);

        }

        else

        {

            Console.WriteLine(“Invalid data”);

        }

    }

}

public class ExpectedClass

{

    public string Name { get; set; }

    public string Role { get; set; }

}

  • Improvements:
    • Uses System.Text.Json for safer JSON deserialisation.
    • Restricts deserialisation to a specific class.

Key Takeaways

  • Validation: Always validate the type and structure of deserialised objects.
  • Library Selection: Choose libraries with strong security features.
  • Avoid Unsafe Formats: Prefer JSON or XML over formats like binary serialization or pickle.
  • Sandboxing: Run deserialisation in isolated environments when dealing with partially trusted data.

By implementing these secure deserialisation practices, you can significantly reduce the risk of CWE-502 vulnerabilities in your software systems.

Business Implications of CWE-502

Financial Impact

  • Direct Costs: Incident response, system remediation, and fines due to regulatory breaches.
  • Indirect Costs: Loss of customer trust and potential revenue decline.

Operational Risks

  • System downtime due to deserialisation exploits can disrupt business operations and damage reputations.

Regulatory Compliance

  • Adherence to standards like GDPR, PCI DSS, and HIPAA often necessitates proactive security measures against deserialisation vulnerabilities.

Case Studies of Successful Mitigation Efforts for CWE-502

Real-world case studies provide valuable insights into how organisations and developers have successfully mitigated deserialisation vulnerabilities (CWE-502). Here are some notable examples:

1. The Equifax Breach: Learning from Failure

Background

In 2017, the Equifax data breach compromised the personal data of 147 million individuals. A significant vulnerability exploited during the breach was related to deserialisation flaws in the Apache Struts framework.

Mitigation Measures Implemented Post-Breach

After the breach, Equifax took extensive measures to prevent future incidents:

  • Library Updates: Equifax ensured all deserialisation libraries and frameworks, including Apache Struts, were regularly updated.
  • Input Validation: A strict input validation protocol was enforced to sanitise incoming data.
  • Application Firewalls: Web Application Firewalls (WAFs) were deployed to detect and block malicious payloads.
  • Enhanced Monitoring: Continuous monitoring systems were implemented to detect anomalies during deserialisation.

Outcome

Equifax successfully rebuilt its security infrastructure, earning certifications like ISO/IEC 27001. This demonstrates the importance of proactive updates and robust input validation.

2. A Major Financial Institution Securing Java Applications

Background

A large financial institution discovered deserialisation vulnerabilities in its core banking applications written in Java. These vulnerabilities were identified during a routine penetration testing exercise.

Mitigation Measures

  • Gadget Chain Analysis: Developers analysed and eliminated unsafe gadget chains in their codebase.
  • Safe Libraries: The institution replaced Java’s ObjectInputStream with safer alternatives like Kryo and XStream configured with security in mind.
  • Type Restriction: Introduced type filtering to ensure only pre-approved object types were deserialised.
  • Deserialisation Sandboxing: The institution implemented a sandboxed environment for deserialisation tasks to isolate potential exploits.

Outcome

The financial institution’s proactive measures reduced its attack surface and improved regulatory compliance. No deserialisation-related incidents have been reported since these measures were implemented.

3. E-Commerce Giant Securing Customer Data

Background

A leading e-commerce platform faced threats from deserialisation vulnerabilities in its microservices architecture. Attackers attempted to exploit insecure deserialisation to access customer data and execute arbitrary code.

Mitigation Measures

  • Switch to JSON: The platform transitioned from binary serialisation formats to JSON, which does not execute arbitrary code.
  • Validation Layers: Implemented strict validation layers using schema validators to ensure deserialised data adhered to expected formats.
  • Service-Level Isolation: Redesigned the microservices architecture to isolate services handling deserialisation from core services.
  • Training and Awareness: Conducted security training for developers to identify and mitigate deserialisation vulnerabilities.

Outcome

The e-commerce platform experienced a significant reduction in successful exploitation attempts, improving customer trust and system reliability.

4. Government Agency Securing Legacy Systems

Background

A government agency managing sensitive citizen data faced deserialisation vulnerabilities in its legacy systems written in C#. The vulnerabilities were identified after a security audit revealed the use of the BinaryFormatter class.

Mitigation Measures

  • Replace BinaryFormatter: The agency replaced BinaryFormatter with System.Text.Json for safer deserialisation.
  • Legacy Code Review: Conducted a comprehensive review of legacy code to identify insecure deserialisation practices.
  • Logging and Monitoring: Implemented extensive logging mechanisms to track deserialisation processes and detect anomalies.
  • Zero-Trust Policy: Adopted a zero-trust approach, rejecting any deserialisation requests from untrusted sources.

Outcome

The mitigation efforts significantly enhanced the security of the agency’s systems, aligning with government standards for data protection.

5. Technology Startup Proactively Addressing CWE-502

Background

A technology startup developing a cloud-based SaaS platform identified deserialisation vulnerabilities during an OWASP ZAP scan. These vulnerabilities posed a risk to customer data stored in the cloud.

Mitigation Measures

  • Fuzz Testing: The startup used fuzz testing tools to identify weak spots in its deserialisation logic.
  • Code Refactoring: Refactored the codebase to remove unsafe deserialisation functions.
  • Deserialisation Proxy: Introduced a proxy service to handle deserialisation securely, sanitising all incoming data before passing it to the application.
  • Runtime Defences: Deployed Runtime Application Self-Protection (RASP) tools to dynamically monitor and block deserialisation exploits.

Outcome

By addressing the vulnerabilities early, the startup avoided potential breaches and gained a competitive edge by marketing its platform as secure and compliant.

6. Mitigation in Open-Source Software Projects

Background

An open-source content management system (CMS) faced repeated reports of deserialisation vulnerabilities through its bug bounty programme.

Mitigation Measures

  • Community Collaboration: Leveraged the open-source community to identify and fix deserialisation weaknesses.
  • Secure Defaults: Updated configuration defaults to use secure deserialisation libraries and disable insecure features.
  • Documentation Updates: Provided detailed guidance for developers and users on how to configure the CMS securely.
  • Automated Testing: Integrated automated security tests to detect deserialisation vulnerabilities in future updates.

Outcome

The CMS improved its security posture and regained the trust of its user base, evidenced by increased adoption and positive community feedback.

Key Lessons from Successful Mitigation Efforts

  1. Proactive Identification: Regular security assessments, including penetration testing and code reviews, are critical.
  2. Technology Choice: Opt for safe deserialisation libraries and avoid insecure ones like BinaryFormatter or pickle.
  3. Input Validation: Never trust external inputs without robust validation.
  4. Isolate High-Risk Operations: Execute deserialisation in sandboxed or isolated environments.
  5. Regular Updates: Keep libraries and frameworks up-to-date with the latest security patches.
  6. Educate Developers: Train development teams to recognise and mitigate CWE-502 vulnerabilities.

Mitigating deserialisation vulnerabilities like CWE-502 requires a multi-pronged approach combining technical, procedural, and educational strategies. These case studies demonstrate that, with the right measures, organisations can successfully defend against this threat, ensuring the security and integrity of their systems. By learning from these efforts, you can implement best practices to safeguard your applications effectively.

Final Thoughts

Deserialisation of untrusted data (CWE-502) is a formidable challenge that demands unwavering attention from software developers and architects. Its inclusion in the 2024 CWE Top 25 Most Dangerous Software Weaknesses serves as a clarion call to prioritise secure coding practices and implement robust defences.

Deserialisation-of-Untrusted-Data-KrishnaG-CEO

By adopting the strategies and tools discussed in this post, you can safeguard your applications against CWE-502 and uphold the principles of secure software design. Remember, security is not just a technical requirement but a cornerstone of trust and business continuity. As the digital landscape grows more complex, staying vigilant and proactive is the best defence against evolving threats.

Empower your organisation by making security a non-negotiable priority. Together, we can build a safer digital future.

Leave a comment