Virsec Hack Analysis Lab: Deep Dive into the Equifax Breach
By Satya Gupta, September 11, 2017
The massive data breach announced by Equifax late last week has sent shock waves throughout the financial and security industries. In the wake of the damage to consumers and the business, we need to understand how this occurred and how breaches like this can be avoided in the future.
According to a report from research analyst Jeffrey Meuler, with Baird Equity Research, a vulnerability in Apache Struts was blamed for the breach. Equifax has similarly pointed to Struts as the cause of their breach, claiming it did not affect internal systems. This is small comfort, if data from 143 million consumers was exposed by non-internal systems...
There is some dispute based on the timing of the breach as to whether the latest Apache Struts vulnerability (CVE 2017-9805) was to blame, because it wasn’t discovered until July 2017, after Equifax was likely breached In fact, the Apache Foundation has vigorously refuted blame for the breach.
Nevertheless, the CVE 2017-9805 vulnerability has apparently existed for over nine years and advanced hackers have a long track record of exploiting zero-day vulnerabilities before they have been officially “discovered.” Plus, there have been multiple vulnerabilities to Apache Struts documents in 2017, going back to March 10 (CVE 2017-5638) – well before Equifax was breached.
Being open source software to begin with, it’s widely known (to hackers too) that Apache software has various vulnerabilities—many known and some we likely have yet to identify. All the more risky for businesses holding highly sensitive data to abandon a routine patch schedule – you may as well hold out a ‘hackers welcome here’ sign. And that’s just for the known vulnerabilities. Even a disciplined patch schedule won’t help you at all with zero-day attacks. At the end of the day, whether Equifax was guilty of laxed server patching, or hackers exploited a previously unknown threat – or a combination of both, the results have been catastrophic and there is plenty of blame to go around.
Eight Known Vulnerabilities in Apache Struts
Following is a list of eight Apache Struts vulnerabilities documented in the National Vulnerability Database (NVD). Based on the date Equifax discovered the breach, it appears likely that the specific vulnerability used by the bad actors was either CVE-2017-5638, CVE-2017-9791, or CVE-2017-9805.
| # |
CVE # | First Disclosure | Brief Description of Vulnerability | Exploit Available Publicly? | Impact on Confidentiality? | Vendor Security Bulletin | Protected by Virsec Platform? |
| 1 | 2017-5638 | 03/10/2017 | Mishandled file upload lets attacker launch commands remotely | Yes | Very High | S2-046 | Yes – Command Injection |
| 2,3 | 2017-7672 2017-9804 | 07/13/2017 | User provided URL in forms can trigger a denial of service attack | No | None | S2-047, S2-050 | Not Applicable |
| 4 | 2017-9791 | 07/10/2017 | Strategic malicious value provided to ActionMessage functionality can result in a remote code execution attack | Yes | Very High | S2-048 | Yes – Command Injection |
| 5 | 2017-9787 | 07/13/2017 | Using Spring AOT functionality in an app can lead to denial of service | No | None | S2-049 | Not Applicable |
| 6 | 2017-9793 | Using outdated XStream Library with REST Plugin can cause Denial of Service attack | No | None | S2-051 | Not Applicable | |
| 7 | 2017-9805 | 06/06/2017 | REST Plugin with XSTREAM handler mishandles XML deserialization | Yes | Very High | S2-052 | Yes – XML Injection |
| 8 | 2017-12611 | 08/07/2017 | Freemarker utility allows read only tag expressions to be written to | Yes | Very High | S2-053 | Yes – Command Injection |
So how do bad actors go about their business of exploiting these and other vulnerabilities? They first start by looking for a service and its version information using tools such as NMAP Scripting Engine. For example to find if a web server is vulnerable to the first Apache Struts vulnerability, one could use this script. In some other cases, enough information can also be gathered using browser-based tools. Next, the bad actor scours the Internet for exploit kits. Many exploit kits such as Metasploit, Exploit-DB are freely accessible.
Could Virsec Have Stopped This Type of Fileless Attack?
In two words – Yes, absolutely. Virsec is uniquely capable of detecting and blocking these types of zero-day fileless exploits – even if current patches have not been applied. Rather than depending on updating signature databases, or diligently applying the latest patches, Virsec can detect the rogue actions taken by hackers to manipulate applications across the stack – from web servers to process memory. If Equifax’s web servers had been protected by control flow technology such as Virsec’s Trusted Execution, the attacks would have been spotted in real time at multiple points, and easily stopped before damage was done and before sensitive information was stolen.
Here are some additional best practices we recommend for any organization concerned about avoiding their own disastrous data breaches:
- Patch data center applications: You’re always better off applying patches promptly but keep in mind that this won’t stop zero-day exploits
- Be situationally aware: Watch CERT databases, vendor and OS advisories, and subscribe to hacker channels.
- Perform regular vulnerability scans: Keep an eye out for internal configurations that can lead to leaks
- Organize war games: Red-Blue Team simulations can often lead to surprising discoveries
- Monitor data traffic: Track daily and hourly data extraction for all users and look for anomalies
- Protect apps at the process memory level: Use pro-active control flow technology like Virsec’s Trusted Execution to protect all critical applications
