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.”
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.
There are 3 main types of deserialization attacks:
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:
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.
About OWASP Top 10 2017 – A8 Insecure Deserialization
Kiuwan Code Security can help you identify and remove security vulnerabilities from your code.
