Open source vulnerabilities tripped Equifax, how can you defend yourself?

Equifax, a credit monitoring giant, disclosed last week it was breached, exposing highly personal data of 143 million people, and stated the root cause was vulnerability in Apache Struts, a highly popular Java library. The company fumbled its response to the attack, and keeping our data secure is their responsibility. However, they’re definitely not the only ones exposed to Struts or other open source library vulnerabilities.

Equifax was likely compromised by either the trivial-to-exploit Remote Command Execution (RCE) vulnerability disclosed last March or the newer RCE vulnerability from last week, which is almost as bad. Despite a relatively large noise level around these issues, consumers of the packages are extremely slow to address them.

We inspected roughly 1,000 open source projects on GitHub that require Struts directly, and 64% of them are still vulnerable to the severe vulnerability from March. Practically all of them are vulnerable to the flaw disclosed last week. Separately looking at the thousands of Java projects tested by Snyk, 78% were susceptible to the March RCE when first scanned, and 100% were vulnerable to last week’s issue (we subsequently alerted users to these issues and helped get them fixed).

The risk from these vulnerabilities isn’t theoretical - they present a real and immediate threat. Following the disclosure of Struts’s March RCE, we’ve seen a large and growing number of attacks in the wild, taking advantage of this known and easily exploited security hole. Similarly, the vulnerability disclosed last week is leading to large waves of attacks.

Who’s responsible?

Breaches tend to trigger a series of finger pointing, each entity involved trying to blame another for this disaster. Unfortunately, open source security ownership is a complicated topic…

In this case, it’s easy to point a finger at Apache Struts.

Over the last decade, over 40 vulnerabilities in Apache Struts were disclosed, including severe ones like the RCE issues mentioned before. This may lead you to think Struts is an insecure library, but that is far from the truth. Its team was actually fast and responsible in addressing found issues, and — unlike many open source projects — even bothered porting important fixes to older and less maintained versions of the software. Apache posted a well written response on the Equifax incident itself.

The next to blame are the Equifax developers who authored the breached portal.

They chose to use a third-party, open source library, without checking if it had known vulnerabilities or monitor for such over time, which ended in disaster. These developers are indeed responsible, as building secure software is a part of their mandate. However, it’s important to remember developers are not security experts, and many are not aware of the risk involved in using an open source library. In addition, developers in large organisations like Equifax are often not empowered to “think outside the box” and take ownership of more than what was explicitly requested.

Dealing with formal responsibilities lays the fault at the Equifax security team feet.

They are the ones formally tasked with keeping their systems safe, and they clearly failed to do so. While there’s no doubt this was a failing on their behalf, if Equifax’s security team is like any other I’ve seen, they are likely not set up for success in securing their company’s applications. Security teams are often outnumbered by developers 100 to 1, and simply cannot keep up with the pace of modern software development, further boosted by these very open source libraries. If the security team is the only one responsible for operating security, a major breach is all but guaranteed.

Which gets us to the final owner of this fiasco — the Equifax executive team.

They are morally and legally the custodians of our personal data, and decide how much to invest in protecting it, even at the expense of profits and growth. They are also responsible for getting the entire company to care about security, and not limit it to a small team. Lastly, it’s their job to understand that using modern dev practices such as open source libraries also brings with it new risks, and that those risks must be managed well. I have no caveats for the exec team’s responsibility, except to say no organisation is bullet proof, and failure does not necessarily imply negligence or incompetence.

How to not be the next Equifax

Instead of focusing on blame, let’s take a moment to discuss how can you keep your company from being the next in the security breach hall of fame. Here are some suggestions for what you can do to protect yourself, now and continuously.

1. Get tested. Run your applications through an open source security tool that flags vulnerable open source libraries, including the Struts RCEs, and be sure to test all of your apps.

2. Fix the problems you find. Taking the blindfold off and seeing the vulnerable libraries is a necessary first step, but if you don’t fix the issues you find, you’re just as vulnerable. Don’t stop at logging the vulnerabilities as issues, get them fixed.

3. Monitor vulnerabilities in the libraries you use. Testing for vulnerable libraries now is great, but you can be sure new vulnerabilities will be found tomorrow, as we’ve just seen with Struts. Set yourself up to get alerts about newly disclosed vulnerabilities, and to be able to fix them before the attackers exploit them.

4. Find security tools developers can use. Your security team does not scale, and developers have different requirements from their tools than security people. Find security tools developers can love, and get your dev teams to use them. Just like we’ve done with DevOps, we need more people to own security (often referred to as DevSecOps).

If you’re not sure where to start on all of those, start with a scan using Snyk’s CLI or GitHub integration. I’m clearly biased in suggesting it, but at the very least Snyk’s free tier will flag the issues in your apps and get you on the path to fixing them. If you don’t want to use Snyk, find another tool, but do something about this problem before it blows up in your face.

This is not a Struts problem

Lastly, it’s worth noting this is not a problem limited to Struts, nor the Java Maven system. In the last month alone, an Arbitrary Code Execution vulnerability in the popular Node.js npm package pg was disclosed, as well as a Cross-Site Scripting vulnerability in the Python framework django.

In the month before that, disclosed vulnerabilities included an XSS in Spark Core, a popular Java-based big data platform, and dozens of malicious packages were discovered in the npm registry. Studies performed earlier this year show that 77% of websites use a vulnerable JS library on their homepage.

The stats go on and on. The bottom line is tracking and fixing vulnerabilities in your open source libraries is a must for any organisation today, and the only way to truly address it is to build it into your development process. If you need some advice on how to take it on, email us and we’ll help you get going. But whatever you do, learn from Equifax’s mistake and don’t stay complacent.