Deep dive into the Equifax breach and a Struts vulnerability

In this post, we will have a look at the technical details of the Equifax breach and the Apache Struts vulnerability, and learn how this could have been prevented.

How did the Equifax breach happen?

Equifax is using Apache Struts, an open-source MVC Java framework for their web-application.

Struts is a popular target for attackers as approximately 65% of Fortune 100 companies use Struts-based applications according to statistics. In the past year, several vulnerabilities have been found in the software and two of them were RCE (Remote Code Execution) bugs.
In case of an RCE, attackers could run code on vulnerable servers, which allows them almost anything they want: to steal company secrets or customer data, upload ransomware, inject malicious code into the web-applications, and much more. It’s no fun to let evil visitors run their code on our servers.

The first Apache Struts vulnerability has been found in the Jakarta Multipart parser on March 10, 2017. It turns out that invalid Content-Type headers are not processed as text but as OGNL code.
These native payloads will be converted to executables and dropped in the server’s temp dir. It’s as dangerous as it sounds, no wonder it has a maximum (10.0) score on CVE Details.

Immediately patching CVEs (in hours, but at least in few days) should be self-evident,
however many companies are failing to update known vulnerable components for months or even years and it looks like Equifax is one of them.

When did the Equifax breach happen?

Let’s see the timeline of events:

• March 10, 2017 Publish date of CVE-2017-5638 (this vulnerability was exploited by the attackers)
• May 13 through July 30, 2017 Series of unauthorized accesses to sensitive files containing customer data on Equifax servers (based on the company’s investigation)
• July 29, 2017 Equifax’s Security team discovers the suspicious network traffic

We should understand that developing and patching processes are longer and more complex at large companies, although large companies should understand the importance of patching security vulnerabilities as well, because their size is no excuse for leaving private information of their customers unprotected.

There are several tools that can help you find and fix security issues in your dependencies.
If your software has 3rd party components as many applications today and you’re not using one of the dependency checker tools, this could be the first step to secure your application. One example is Snyk that continuously finds and fixes vulnerabilities in your dependencies.

Struts REST

The second RCE vulnerability CVE-2017-9805 (discovered on September 5, 2017) was in a plugin called Struts REST. It allows attackers to post XML formatted data to application endpoints. The XML format is supported by a library called XStream, which can be used for serialization (converting data structures or objects into a format that can be stored or transmitted and reconstructed later) as well.
That means, a specially crafted XML input could be translated into a malicious Java object and the code of the attacker will be executed.
You might think the web-application is vulnerable only if it is used with XML, but this is not the case. Struts REST is poorly configured by default, so installing this plugin makes the application vulnerable – even the struts2-rest-showcase.war official example application is exploitable.

You are wrong if you think you have to be a hardcore hacker to launch successful attacks against vulnerable Apache Struts instances. Exploiting public vulnerabilities is often just about parameterizing a python script with a URL.

XML generated XStream

It’s hard to implement deserialization securely because after the serialized data is processed its code has already executed. XStream is very honest about it as you can see in their Security Aspects:

The XML generated by XStream includes all information required to build objects of almost any type. This introduces a potential security problem.
The provided XML data is used by XStream to unmarshal Java objects. This data can be manipulated by injecting the XML representation of other objects, that were not present at marshalling time. An attacker could take advantage of this to execute arbitrary code or shell commands in the context of the server running the XStream process.

Software is made by people, so don’t assume it’s flawless. You can, however, defend your application against many 0-day vulnerabilities too. If you are using 3rd party components, take your time to configure them properly, read the documentation, disable unnecessary features and remove extra libraries. These precautions can significantly reduce the attack surface.

The most important takeaways from the Equifax breach:

• Validate user input It’s the root cause of many attacks (XSS, Command Injection, etc.)
• Configure your components properly Turn off every feature you’re not using to reduce the attack surface.
• Monitor vulnerabilities and update your 3rd party softwares regularly Train your DevOps and sysadmin team to prudently maintain third-party software or use automated solutions, like Snyk or Black Duck.