OWASP Top 10 2017 – A8 Insecure Deserialization

Aug 15, 2019

In 2017, OWASP added a new vulnerability to the Top 10 list: A8 Insecure Deserialization, in place of the previous #8 vulnerability, Cross-Site Request Forgery.

According to OWASP, “Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.”

To understand this vulnerability, let’s take a look at the process of serialization. Imagine that a programmer wants to save user data, such as login information, the items in a web shopping card, the points accumulated in a mobile game, etc. A typical approach is to “serialize” the data into an easily-transmittable format such as JSON or XML.

When an application needs to access the data, it fetches the serialized data and reconstructs it. This process is called “deserialization.” But, the reconstruction process introduces a vulnerability if the data is from an untrusted source. For example, the data could be corrupted with code that executes during the deserialization process to grant an attacker administrative privileges. OWASP describes such remote code execution attacks as “one of the most serious attacks possible.”

The Consequences of Insecure Deserialization: The Equifax Breach

To understand the possible effects of an insecure deserialization attack, let’s explore the case of the 2017 Equifax breach.

Although the Equifax breach affected far fewer individuals than the 2013 Yahoo data hack, it is considered by far the worst breach of the two, due to the nature of the information stolen. The Yahoo hack may have affected 3 billion accounts but didn’t include information such as credit card info and bank account data. On the other hand, the 143 million accounts affected by the Equifax breach involved the theft of Social Security numbers, driver’s license numbers, and credit card numbers. As a result, these consumers were forced to rely on credit freezes, manual monitoring of bank accounts, and fraud alerts to minimize the consequences of the breach in their personal lives. Thus, it comes as no surprise that 23 class-action lawsuits were filed against Equifax for the egregious breach.

So, what caused the Equifax breach? Industry experts maintained that the breach occurred as a result of an insecure Apache Struts framework (CVE-2017-9805) within a Java web application, which led to the execution of arbitrary code on Equifax web servers. Meanwhile, Apache disputed this rationale. Apache maintained that the more likely vulnerability is a compromised CVE-2017-5638 in connection with the Jakarta multipart parser.

In mid-September 2017, Equifax confirmed that the CVE-2017-5638 vulnerability led to the breach but provided no details to support the claim. Thus, speculation abounds about the possible role CVE-2017-9805 (deserialization vulnerabilities) may have played in Equifax’s breach.

The Apache Struts REST (Representational State Transfer) plugin supports XML through XStream, making the serialization of complex data objects into strings of text characters possible. However, this welcomed convenience also allows malicious XML payloads to be introduced into Struts servers during the deserialization process.

Due to hackers exploiting an application flaw to steal sensitive consumer data, now 143 million Equifax customers must rely on credit freezes, manual monitoring of their bank accounts, and fraud alerts to minimize the consequences of the breach in their personal lives. It should therefore be no surprise that 23 class-action lawsuits have been filed against Equifax.

The Types of Insecure Deserialization

There are 3 main types of deserialization attacks:

Blind deserialization attacks: Blind attacks occur behind restricted firewall-protected systems or networks with strong security manager policies in place. Hackers can either exploit the Java payload or manipulate a chain of Transformers to facilitate RCE (Remote Code Execution).
Asynchronous deserialization attacks: This type of attack stores serialized gadgets in databases. When the target application commences deserialization, gadget chains programmed to compromise the process will be executed in JMS broker client libraries. Vulnerable JMS libraries include the Oracle OpenMQ, Oracle Weblogic, IBM WebSphereMQ, Pivotal RabbitMQ, Apache QPID JMS, and Pivotal RabbitMQ.
Deferred-execution deserialization: In this type of attack, gadget chains are executed after the process of deserialization. In both deferred-execution and asynchronous deserialization, gadget chains are sequences of ROP (return-oriented programming) gadgets that end in RET (return from procedure) instructions. These gadget chains facilitate the exploitation of vulnerable applications by bypassing non-executable page protections such as read-only memory and kernel-code cohesion protections. ROP gadgets are not dependent on binary code injection; hackers need only link executable addresses to the requisite data arguments to facilitate code execution. Thus, ROP gadgets are becoming a popular way for hackers to exploit the deserialization process.

Did the Equifax Hackers Exploit a Deserialization Vulnerability in Apache Struts?

There are essentially two types of ROP gadgets: one that ends with RET instructions and another that uses replicated transfer information to simulate RET instructions. These gadgets allow hackers to bypass weak or inadequate exploit mitigations during the deserialization process. If the Equifax hackers exploited a deserialization flaw in Struts, this is how they might have done it:

The hacker focuses on obtaining control of the stack pointer and program counter. By obtaining control of the program counter, he can facilitate the execution of the first gadget. Next, control of the stack pointer allows the RET instructions on his gadget chain to transfer control between gadgets.
Immediately after, the hacker overflows the buffer by injecting malicious data into the system, corrupting the memory in the process. He appropriates the code execution process by putting in place his own input buffer and gadget chain containing multiple return-to-libc calls.
The original return address is now replaced with the return address of the first gadget in the chain. Code execution continues until the RET instruction is encountered in the last gadget.
A VirtualAlloc function is called to facilitate the allocation of a new memory region, where a malicious shellcode or ysoserial payload can be placed. Once the payload is in place, program flow is transferred to this new memory region. Then, when the “infected” program/application begins the deserialization process, the malicious payload is activated, allowing the hacker to gain complete control of the system.

How to Protect Your Applications Against Insecure Deserialization

In September 2017, the Apache Struts Project Management Committee confirmed that Equifax’s failure to install patches led to the unfortunate breach. Subsequently, a patch was released for CVE-2017-9805, with Apache announcing that developers should upgrade to Struts version 2.5.13.

Meanwhile, vendors are also turning to blacklisting and whitelisting to mitigate the exploitation of insecure deserialization processes. Blacklisting refers to the practice of prohibiting emails, domains, software, and apps recognized as unsafe. Whitelisting, on the other hand, authorizes access to an exclusive list of users, software, and domains.

Although both methods can be effective, they are not exhaustive solutions. Instead, they need to be combined with methods that will neutralize the effectiveness of gadget chains, the most popular variations of deserialization attacks, and attacks via HTTP, JMS, JNDI endpoints (to name a few).

These methods include hardening java.io.ObjectInputStream class behavior by subclassing it, using in-place code randomization, and deploying ASLR (Address Space Layout Randomization), which randomizes memory addresses and allocates them in a dynamic manner. With ASLR, memory addresses are not static; each time an application commences deserialization, memory regions, and stack pointers are given new base addresses.

US CERT (the United States Computer Emergency Readiness Team) has just issued a warning about a previously unknown vulnerability in ASRL. Developers should be aware of that. It recommends applying a temporary fix until a patch is released.

To find out whether your application is susceptible to an insecure deserialization attack and to deploy effective mitigation solutions, schedule a Kiuwan Code Security demo today. At Kiuwan, protecting your company from an Equifax-type breach is our first priority.

Learn more in our complete OWASP Top 10 2017 series:

About OWASP Top 10 2017 – A8 Insecure Deserialization

Kiuwan Code Security can help you identify and remove security vulnerabilities from your code.

Get Your FREE Demo of Kiuwan Application Security Today!

Identify and remediate vulnerabilities with fast and efficient scanning and reporting. We are compliant with all security standards and offer tailored packages to mitigate your cyber risk within the SDLC.

FREE DEMO