The Equifax Hack: 6 Months Later, What Did We Learn?
Table of Contents
When news broke that credit rating agency Equifax had been breached, resulting in the theft of personally identifiable information (PII) records, it seemed like the company was yet another victim in a long line of organizations to have been successfully targeted by hackers.
However, this case was different than the others. We soon learned that this was the largest single breach in history, with an initial 143 million records being reported, a number that later grew to over 145.9 million as more details were uncovered later down the line.
For those who follow breaches — how they occur and the responses to them — Equifax was a perfect storm where everything that could go wrong did, all with fantastically catastrophic results for all involved.
In the time since the breach was announced back in September 2017, a lot of pixels have been discolored describing the events, piecing together a timeline for us and painting a picture of how chaotic this has been.
The timeline
According to the SANS Institute, a leading publisher in the security space, the U.S. CERT disclosed the vulnerability in Apache Struts2 on March 10, 2017. It was at this time that the CVE was posted to the National Vulnerability Database (NVD).
Apparently working around the clock, the good folks over at the Apache Foundation were able to release a security update that worked as a patch for the vulnerability already on 19 March, barely over a week later.
Nearly two months later, according to Equifax’s own statements, the company believed that the compromised records were first accessed by the hackers on May 13, 2017. This means that they were left unprotected for just under two whole months after the patch had become available, giving the attackers a very wide-open window to carry out their malicious operations against the company.
Again based on the company’s own reporting, it was only on July 29 that members of their security team began to notice suspicious traffic connected with their online dispute portal web application for the U.S., leading them to take action by locking down the connection. The following day they took the web application offline, hoping to stem the flow from the leak and get a sense of where they stood.
To this end, on August 2 they brought on the FireEye-owned cyber security firm Mandiant to help them carry out their investigation. By August 15, investigators realized that the hackers had not just gained access to dispute documents, but through a series of webshells that they installed on their compromised hosts that gave them movement inside the system for exfiltrating the data, had breached their way into the company’s holy of holies.
Finally three weeks later on September 7, the company made the news of the breach public. In just a matter of days, many in the top leadership roles began to resign as the outrage quickly took over.
However, as bad as the situation for Equifax looked, it was only the beginning of their troubles as they messed up every response in the book, digging themselves a deeper hole.
When you think you’ve hit rock bottom, don’t stop digging
Of Equifax’s many sins, the one that feels the most egregious even if it harmed the least amount of people was the fact that a small number of executives decided to sell their stock in the company soon after learning of the data breach.
The Financial Times reports that former global chief information officer Jun Ying exercised all of his options, selling them for just under $1 million, an hour after using Bing to search what had happened to credit reporting firm Experian’s stock price after they were hacked backed in 2015.
This move was deemed as unhelpful for the company’s public image given the events, and Mr. Ying was quickly given the boot from the company. This month, it was announced that he has been charged with insider trading.
The second offense falls somewhere between appearing to be helpful and just angering users more.
Equifax had set up what was possibly the phishiest sounding website of all time, hxxp.equifaxsecurity2017.com, where folks could go in and check out if they had been affected by the breach. As Brian Krebs points out, besides the site getting flagged as a phishing site, it sent visitors on a wild goose chase by giving them different information depending on whether they looked themselves up on a mobile device or desktop.
This attempt at damage control was only made worse when the text on their offer to provide a year of free credit monitoring included language indicating that by signing up for the service, consumers were waiving their rights to join in any class action lawsuits.
The company tried to walk this back with statements that this statement did not apply to those affected by the breach, but the situation remained a bit of a “dumpster fire” as Krebs termed it.
Looking back
With roughly half a year having gone by since the news of the breach, there are a number of reasonable assumptions that we can make about what lead to the hack, and about the reaction.
The first assumption is that Equifax did not have the right kind of tool in place for dealing with open source security. While they may have had application security testing tools for their in-house written code like Static Application Security Testing (SAST) or Dynamic Application Security Testing (DAST), they were not using a Software Composition Analysis (SCA) tool that was working continuously to identify open source components in their inventory and products.
Records show that Equifax had been contacted by the U.S. authorities to warn them about the vulnerable Apache Struts2 component. However, the fact that they did not carry out a patch over the two month period before the breach began would indicate that they were unaware that they had the component in their products.
If they had been using an SCA tool, they would have been alerted that one of their products had a risky component, and they could have responded accordingly.
Simply put, you cannot patch what you don’t know you have.
Looking forward
In the aftermath, the industry appears to have woken up to the issue of open source security, with every organization wanting to avoid being the next Equifax. Organizations are realizing that if they are developing software, then they are almost assuredly using open source components.
If the Equifax case has proved one thing it is that companies need to take responsibility for their open source components, if only because the public has little empathy for a company that exposes their data — regardless of whether the vulnerability was in their network hygiene, in-house code, or an open source library that a low level developer copied from GitHub.
