Equifax Breach: Legal, Vulnerability Blame Game, and the Big Technical Debacle

This is the second blog in the running series on the Equifax data breach.

  1. Equif*@#$d: Equifax Breach Response Off To A Rough Start
  2. Equifax Breach: Legal, Vulnerability Blame Game, and the Big Technical Debacle
  3. Equifax Breach: EULAs, Size Doesn’t Matter, and Where’s The Data?
  4. Equifax Breach: The Bigger Picture, Identity, Impact, and Advice
  5. Equifax Breach: Ambulance Chasing, FireEye, and a News Roundup
  6. Equifax Breach: Timeline, International, Patching, Gender, PCI, oh my!

As we previously posted, the Equifax data breach response got off to a very rough start. Before we get into the thick of this update, Risk Based Security would like to remind everyone that in the wake of a breach of this severity, it is important to be very cautious. Like after any disaster or tragedy, there are already criminals looking to prey on victims that want to quickly protect themselves. In the context of a credit bureau breach, this will mean sketchy ‘services’ that promise to protect your identity, tell you if you were part of the breach, or other types of snake-oil that is too good to be true. As always, make sure that you get both information and services from reputable companies with an established background. Further, when reading about the aftermath of any data breach, remember that the ‘facts’ tend to change on a day-to-day basis as more analysis is done.

Legal Fallout, Congressional Inquiry, and Regulation

The last few years, we’ve  noticed lawsuits are being filed against breached organizations extremely fast – sometimes in the space of hours after the breach is announced. With Equifax, not only did a class-action lawsuit get filed the same day as the announcement, but they are seeking as much as $70 billion in damages. This is believed to be the first-ever billion-dollar class action lawsuit.

Similarly, after a large breach that impacts many Americans, we occasionally see Congress take interest in the incident. With Equifax and the potential fallout, both Senator Ron Wyden of Oregon and Representative Ted Lieu of California have called for Congressional inquiry into the incident. Senator Wyden went on to tell Forbes, “I’ve said for years that companies need to be held accountable for data breaches, which is why I’ve supported Senator Leahy’s legislation to require strong protections for consumer privacy.According to Eric Geller, Equifax briefed the House Energy and Commerce committee on the breach the day after the breach was reported, ahead of a hearing announced by Committee Chairman Greg Walden.

While Congressional action on breach events is rare, it is much more common to see state Attorneys General stepping in to investigate. By Friday afternoon, New York Attorney General Eric Schneiderman launched an investigation of Equifax. In his statement, Mr. Schneiderman made his intent clear:

“The Equifax breach has potentially exposed sensitive personal information of nearly everyone with a credit report, and my office intends to get to the bottom of how and why this massive hack occurred,”

Natasha Lomas wrote a great article for TechCrunch pointing out that while the majority of people impacted are American, Equifax does have a European presence and has said that some UK and Canadian citizens were also impacted. This means that this particular breach at Equifax would have “failed Europe’s tough new rules”. Specifically, she refers to the General Data Protection Regulation (GDPR) which is a regulation that will standardize breach notification throughout Europe, agreed upon by the European Parliament, the Council of the European Union, and the European Commission. While there are permitted exceptions to reporting breaches in a specific time frame, one key aspect to keep an eye out in the near future is the possibility of substantial monetary fines. The GDPR will give the power for sanctions to be imposed which are considerable. For example, under the regulation, Equifax could have faced a fine of up to 20,000,000 EUR (USD $24.07 million) or 4% of the annual worldwide turnover of the preceding financial year. Given Equifax’s 2016 operating revenue was around USD $3.14 billion dollars, that fine could have been as high as USD $62.9 million dollars.

Considering 209,000 credit or debit card numbers were also compromised, Equifax will most likely end up with other additional costs such as a PCI assessments for any fraudulent transactions, as well as fines and penalties.

The Vulnerability Blame Game (or Let’s Not Leap to Conclusions)

After any breach, many in the Information Security industry are very curious about how it happened and who was behind it. In rare cases an organization will be forthcoming about the compromise, perhaps stating it was the result of a phishing campaign or stolen credentials. So far, Equifax has only said criminals “exploited a U.S. website application vulnerability to gain access to certain files.” That can mean a lot of technical real-estate in the big picture, and doesn’t give a hint if this was due to a specific commercial application, application framework technology, third-party library or custom application code written by Equifax.

Yet, William Baird & Co. has issued a report on the data breach, saying that the flaw that was exploited was in Apache Struts, an open-source framework used to create Java web applications.

It is important to note that this three page report (ignoring the Appendix) only mentions “the Apache Struts flaw” twice, and gives no details beyond that. This is dangerously misleading in many ways and leads to several questions. First, “their understanding” means what exactly? Were they part of the auditing efforts after the breach was first detected? Do they have insider knowledge of the forensic analysis done at Equifax? Are they relying on an unnamed insider source at Equifax? Second, since Apache Struts has released details of two vulnerabilities in the last three days, one of which is pure remote code execution, the other a context-dependent (a.k.a. user-assisted) code execution issue, almost every reader will assume it is one of those two. Third, there were two other remote code execution vulnerabilities in Struts announced earlier this year, including “Struts-Shock”, a named vulnerability that has had public exploit code available since March 9, 2017. Using the term “the Apache Struts flaw” is not precise and suggests quick speculation at best, not analysis of the facts. If we look at VulnDB we can see a total of 75 vulnerabilities dating back to 2005, with many in the past couple years.

While definitely a potential, making a hasty conclusion that the flaw exploited is in Apache Struts doesn’t help anyone. This report was covered by Keith Collins for QUARTZ, among others, who cited the study and then made additional conclusions, whether he intended to or not. On the upside, Collins mentions that “the apache Struts flaw” in question was “announced earlier this week on Sept. 4” (Note that it was actually published Sept 5, and he cites the original source that confirms it.) So we have Baird and QUARTZ who suggest or explicitly say it was the recent vulnerability. Collins goes on to cite the original vulnerability disclosure and reference that it specifies the issue is in the REST plugin. With this article’s language and citations, it is basically putting forward as fact that the vulnerability exploited to compromise Equifax was the September 5 “Apache Struts REST Plugin XStream XML Request Deserialization Remote Code Execution” issue.

Not only is the lack of citation for this information troubling, they are also collectively saying that the same vulnerability discovered by Bas van Schaik of lgtm was known about and exploited 38 days before their disclosure. That would be a significant zero-day vulnerability used against a target most likely not required since they apparently are using severely outdated technology (more on that in the next section). It’s fine to guess at the vulnerability used, a lot of people do it, but to state it as fact without showing the provenance of that information is irresponsible and misleading. Attempts to contact Baird by at least one reporter have gone unanswered. In the meantime, an extremely rare event has happened and the “accused” Apache Struts team has released a statement.

The Big Technical Debacle

Putting the vulnerability blame game aside for a moment, it is interesting to evaluate the public technical information that can be gained about Equifax. While Risk Based Security has not published any information on Equifax, many security researchers have shared their findings. No one bit of information in this section will point at or even suggest which vulnerability was used. Instead, this section serves to show that Equifax does not appear to follow the most basic of security practices which calls into question if they were in a position to properly defend their network and people’s personal information.

As mentioned in our original post, Equifax appears to have stood up a WordPress installation on equifaxsecurity2017.com to handle a portion of the breach response. Andrew Healey pointed out earlier that it appears to have a single user account named “edelman”. At some point after his Tweet, Equifax seems to have prevented access as it now throws a 403 error. Dan Goodin posted the full output before it was restricted:

Additionally, a ThreatPost article, stated that “many of the web applications hosted within the Equifax network are written in JSP, and a few pages appear to be coded with ASPX. There also appear to be a large amount of legacy Microsoft IIS web servers in use.” Between the IBM servers, IIS servers, and alleged Apache Struts implementation, there are many legitimate and likely avenues of attack that have nothing to do with the Struts vulnerability disclosed days ago.

There has been a lot more technical information publicly disclosed by researchers examining Equifax’s Internet-facing resources. In a now-deleted tweet, Kevin Beaumont pointed out that Equifax is using outdated IBM HTTP server software with known vulnerabilities. Several people have pointed out that a trivial cross-site-script (XSS) vulnerability publicly reported to affect an Equifax server in 2016, still works. The Open Bug Bounty submission (OBB-141440) is dated March 14, 2016 and is not fixed even with a provided proof-of-concept. However, looking at other OBB reports for Equifax, we see this is contrasted by OBB-141437, an XSS vulnerability in Equifax.co.uk that was fixed within months, as well as OBB-240695 a different XSS vulnerability in Equifax.com that was reported on May 24, 2017 and subsequently patched.

Stepping back a bit to look at Equifax as a bigger picture, one dump of information shows that Equifax owns 1,519 domains with 5,209 sub-domains / aliases, while a different analysis says that they have “618 domains spread across 493 perimeter hosts on ipv4.” Regardless which is more accurate, that is a lot of technical landscape to manage, a substantial attack surface and even more daunting to secure. Shortly after the breach was made public, Twitter user @notdan shared a stack trace from an unknown Equifax resource while examining their systems. As Jake Williams reminds readers, “printing stack traces is indicative of generally bad cyber security practices.” Finally, Kenn White points out that the consumer login page to Equifax was not using a proper SSL certificate as of September 7th.

The story continues with Equifax Breach: EULAs, Size Doesn’t Matter, and Where’s The Data?