The Equifax Breach: Who’s to Blame?

The Equifax Breach: Who’s To Blame?
Table of Contents

Equifax – one of the three main credit rating bureaus in the US, announced in a statement that it had experienced a major data breach, after “Criminals exploited a US website application vulnerability to gain access to certain files”, sometime between mid-May and July.

The breached data primarily includes names, Social Security numbers, birth dates, addresses and, in some instances, driver’s license numbers and impacts 143 million U.S. consumers. This constitutes the biggest leak so far in 2017 and perhaps in the history of the United States: considering that the US population is about 324 million people, 143 million is nearly half of the entire US population.

The data breach is especially alarming both because of the volume of people it affects and the scope of private and sensitive information accessed. This type of personal and sensitive information could potentially be used for identity theft. As one security expert put it: “Imagine if one out of every two people walking down the street dropped their credit card, along with a sticky note on the back with all their personal information needed to access that card. Now imagine that happening in every city across the country.”

Equifax’s original statement didn’t provide a lot of specifics regarding the how, who and when – leaving a lot of room for web-wide guesstimation and finger pointing: Who’s responsible? What did Equifax do wrong?

Who Let the Data Out?

Last Wednesday, a week after their initial announcement, Equifax finally confirmed the rumors that the root cause of the breach was an Apache Struts vulnerability – CVE-2017-5638. This vulnerability was disclosed on March 7, and patched on the very same day – meaning a secured version of Apache Struts was available for developers to update any vulnerable version they might have, since March 7.

The vulnerability was scored as critical (CVSS 10), mainly due to how easy it is to hack. And indeed reports from days after the Apache Struts March vulnerability was released showed that hackers were exploiting it en masse.

Why is Apache Struts Such a Popular Target?

Another reason the Apache Struts vulnerability that was disclosed in March was such a popular target for hackers is that the Apache Struts Web Framework is a very popular programming framework for building web applications in Java, due to its flexibility and extendibility.

When our own research team analyzed our database, which includes over 3M open source components and 70M source files and over 20 programming languages, to learn which popular open source projects are the most vulnerable, Apache Struts2-Core was found to be the second most vulnerable open source project, among the most popular open source projects.

What this means for hackers is that once they locate a vulnerability, they have many lucrative places where they can exploit it.

Mind the Patch

The Equifax exploit began in mid-May: at least two months after the Struts vulnerability was released and the patch was published. Why didn’t Equifax patch it? Straight up negligence, right?

Absolutely – but they are not alone. Unfortunately, too many companies are being negligent when it comes to using know vulnerable open source components.

Security researchers have stated: “At least 65% of the Fortune 100 companies are actively using web applications built with the Struts framework. Organizations like Lockheed Martin, the IRS, Citigroup, Vodafone, Virgin Atlantic, Reader’s Digest, Office Depot, and SHOWTIME are known to have developed applications using the framework. This illustrates how widespread the risk is.”

As of today: how many companies really know if they’re using a vulnerable version, let alone taking action to update it?

The Weakest Link

Apache Struts is currently the most talked about vulnerable open source project, but it’s not alone. Open source vulnerabilities have become the weakest link in companies’ application security. Consider the fact that 33% of data breaches are a result of an attack at the application layer and that these attacks are growing by more than 25% annually and you are presented with the disturbing state of application security.

This is not a new issue to security professionals. In 2013 OWASP updated their top-ten list of what not to do, with their A9 commandment “using components with known vulnerabilities”.

The open source community does its best to address vulnerabilities as soon as they are discovered, and work quickly to create and publish a fixed version. However – much like Equifax, most organizations are not quick to check their libraries for vulnerabilities, or patch them.

While Equifax didn’t do the best job of crisis control – to say the least, when it comes to the root cause, we must face the facts and admit that the Equifax breach exposed a wide-spread problem.

Equifax was no different than almost half of Fortune 500 companies. The Equifax breach was executed through a vulnerability in an extremely popular open source library that’s used by thousands of organizations.

Stay on Top of your Open Source Libraries

Seeing the increased adoption of open source components into every business sector: from startups, to schools and governments, it was clear to us as far back as 2011 that we need to connect the users of open source components with the open source community so they can be alerted when vulnerabilities are discovered and proactively address them.

Manage open source application risk

Recent resources

Mend.io is a Strong Performer in the Forrester Wave™ Software Composition Analysis, Q4 2024

See why Mend.io is recognized as a Strong Performer in The Forrester Wave™ Software Composition Analysis (SCA) Q4 2024 report.

Read more

Mend.io & HeroDevs Partnership: Eliminate Risks in Deprecated Package

Announcing an exclusive partnership between Mend.io and HeroDevs to provide support for deprecated packages.

Read more

All About RAG: What It Is and How to Keep It Secure

Learn about retrieval-augmented generation, one complex AI system that developers are using.

Read more