What Insecure Deserialization Is Capable Of
The new 2017 OWASP Top 10 shows that insecure deserialization has edged out CSRF (Cross-site Request Forgery) from the NO.8 spot. For those who question the potency of an insecure deserialization attack, the 2013 Equifax breach should put all doubts to rest.
Although the Equifax breach is dwarfed in size by the 2013 Yahoo data hack, it is considered by far the worst breach in terms of information stolen. The Yahoo hack may have affected 3 billion accounts, but the 143 million accounts affected by the Equifax breach involved the theft of Social Security numbers, driver’s license numbers, and credit card numbers. Meanwhile, credit card info and bank account data was said to be excluded from the 2013 Yahoo breach.
So, what caused the Equifax breach? Industry experts maintain 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 disputes this rationale. It maintains 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.
The idea of hackers exploiting an application flaw to steal sensitive consumer data is an outrage to our modern sensibilities. Now, 143 million consumers must 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 have been filed against Equifax for the egregious breach.
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 that are recognized as unsafe from accessing sensitive applications. 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.
Developers should be aware, however, that US CERT (the United States Computer Emergency Readiness Team) has just issued a warning about a previously unknown vulnerability in ASRL. 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.