Last week I received a notice my personal information was compromised. It was not a surprise – with 143 million people affected in the Equifax data breach, nearly everyone I know received the same notification. This may be the largest loss of personal data to date and tempers are running predictably hot. For me the breach was less of a surprise. Apache Struts, the possible culprit in this breach, has been one of the most targeted web applications showing up in our Security Operations Center for years.
But even less of a surprise, as we discussed in our webinar on similarly massive data breaches a few weeks ago, is the fact that a data breach of this magnitude happened and a web application was the entry vector. We already know that web application attacks are by far the largest source of breaches in data centers. And with historically low spending on web app security (23:1), we should expect more to come. So this is an especially good time to reflect on whether your organization is fundamentally better protected than Equifax or Yahoo (which was also breached through a web application). If you’re ever going to push for change, now is the time, because everyone is paying attention again to cyber security for a while.
Most Prevalent Incidents in our SOC for the last 18 months.
A lot of ink has been spilled since the Equifax story broke. A bit too much, in fact. In reality, we don’t know much at this stage. Because the laws compel disclosure of the breach to affected users, but do not require any technical details to be shared in public, what we have is mostly hearsay and innuendo. With the Yahoo breach, the news cycle was so cold by the time details were published, no one was paying attention. So what do we know thus far?
Story: Equifax was compromised through an Apache Struts vulnerability.
Fact Check: Unconfirmed (but likely to be TRUE)
This has been a widely reported assertion by media outlets as varied as Quartz, ZDNet, New York Post and even Reuters. In fact, Equifax has not commented publicly on which specific component in their software was compromised. Curiously, this part of the story is extremely thinly-sourced and comes from a single mention in a Baird Equity Research report. Reuters being Reuters identifies Baird as the source for Apache Struts attribution, but also notes that Baird did not reply to Reuters inquiries. It’s entirely likely that details of this data breach were disclosed to an equities analyst during a briefing, but this is not exactly an ideal source for cyber security information. It just happens to be all we have.
Story: Equifax was breached through a 9-year-old cyber security flaw
Fact Check: Most likely FALSE
Just as quickly as the Apache Struts story broke, several media outlets began running an angle that Equifax was compromised through a 9-year-old vulnerability. There are several major credibility problems with this. First, we do not know which specific Apache Struts vulnerability was exploited. At Alert Logic, Struts has been a perennial frontrunner for top 5 critical web application attack incidents (see our Cloud Security Report for more), so it could be any of them in any given year. Second, even if speculation that the most recent Apache Struts vulnerability disclosed last week (CVE-2017-9805) was the culprit, it’s possible this vulnerability was actually a 0-day when it was exploited. Just because Apache Struts versions going back 9 years are vulnerable, doesn’t mean this is a 9-year-old vulnerability.
Story: Equifax failed at securing their web applications, failed to write secure code and failed to implement proper controls.
Fact Check: Partially TRUE
There is no sense citing media stories, as this has been the prevailing sentiment across the board in all social and conventional media forums. The fact is that it’s not specifically Equifax code that failed, because the vulnerability was inherited from the underlying web application component. This is one of the most misunderstood points in cyber security today – web application stacks are complex organisms and you can end up with major vulnerability without trying too hard. Most enterprise cyber security teams spend more time brushing up on the latest activities of Grizzly Steppe and Deep Panda activities than understanding the web application stack their own software teams are using, and these stacks are a major source of risk.
It is true, however, that proper controls would have likely stopped this cyber attack. Most enterprise Web Application Firewalls (WAFs), such as our Web Security Manager Premier service, would have likely stopped this Apache Struts attack. For example, when CVE-2017-9805 was announced last week, the first thing we did was check to see if our WAF service blocks it, and it did so without any additional rules or modifications necessary, which means we would have effectively stopped this attack at 0-day before it was disclosed.
Story: Equifax was negligent and failed to adequately pen test their code.
Fact Check: FALSE
This seems to be a widely held and ultimately wrong assumption. According to Red Monk, as many as 65 percent of all Fortune 500 companies use Apache Struts. This means that even if Equifax failed to perform a penetration test (irrelevant), this REST plugin in Apache Struts was covered extensively by hundreds, if not thousands of penetration testers for close to 9 years. And in those years of testing they found nothing, so this isn’t strictly about Equifax. This assumes that CVE-2017-9805 was the entry vector, but it holds true for any critical Apache Struts vulnerability discovered over the years. The truth is that if these vulnerabilities were trivial enough to be found in routine penetration tests, we would have found them all by now.
Cyber security is hard and penetration testing is not a silver bullet. In this case, only a properly configured Web Application Firewall would have stopped the attack and effective post-compromise detection could have reduced dwell time from 2 months to a much smaller window. That could have been the difference between stopping this breach and losing data for 143 million people.
This story is still very much developing and we will learn more in the weeks to come. If you have questions, or other stories you’d like to scrub through our fact checker, leave us a comment below.