Wow, what a week! Our industry is rippling from all the news surrounding the latest Struts 2 vulnerability and the possibility that another Struts vulnerability was also responsible for the Equifax hack.
“The company says as many as 143 million people in the United States were hit. Others in the U.K. and Canada were also impacted, but Equifax hasn't said how many. Credit card numbers for about 209,000 U.S. customers were compromised, in addition to "personal identifying information" on about 182,000 U.S. customers.”1
Baird has confirmed that the underlying Equifax vulnerability was in Apache Struts. But there have been a number of vulnerabilities in Struts, including two extremely dangerous ones just this week. The rest of Baird’s analysis is nonsense, as these exploits allow a complete remote host takeover, enabling the attacker to steal, corrupt, or delete anything in that database. Depending on the details, this could be serious negligence with regard to protecting SSNs and other PII.
“Significant data breach obviously a material negative, but -13.4% after-hours seems like over-reaction based on our understanding of events. Our understanding is data retained by EFX primarily generated through consumer interactions was breached via the Apache Struts flaw (i.e., core databases not believed to have been breached). We expect near-term operating headwinds plus material event-related expenses. However, we believe EFX's access to key data sources are unlikely to be affected, and client relationships and EFX's brand are unlikely to be meaningfully impaired intermediate to long term.”2
In my mind, there are two Struts vulnerabilities that jump out as possibilities. The first is far more likely, but the second is a very remote possibility:
- CVE-2017-9805 was made public this week and while also very serious, is rated a 7.5/10. This attack is also a single HTTP request but this time contains an unsafe serialized object. This attack might require authentication and does not apply to every instance of Struts. Only those with the struts2-rest-plugin are vulnerable. In this case, the attack Contrast has been monitoring for exploit attempts since the release, but has not yet seen attacks.
The first vulnerability from March seems much more likely because it’s easier to exploit and much better known. It also fits the timeline better, since it was released months before Equifax was attacked in July. Contrast has also been monitoring and blocking widespread attacks against CVE-2017-5638 for many months from all over the world, including China, Hong Kong, and India. The second CVE is possible, but would mean that the attackers had this vulnerability before it was publicly released.
Ensuring that you don’t use libraries with known vulnerabilities is a good practice, and has been in the OWASP T10 since 2009, when I led the charge to add it. Keeping libraries up to date isn’t a small amount of work, as these changes come out frequently. Often these changes require rewriting, retesting, and redeploying the application, which can take months. I have recently talked with several large organizations that took over four months to deal with CVE-2017-5638. Even in the best run organizations, there is often a gap of many months between vulnerability disclosure and updates being made to applications.
Therefore, we believe every application and API should include Runtime Application Self-Protection (RASP) technology, which can deploy protections against this type of vulnerability immediately across an application portfolio, without any changes to code. With automated exploit scanning coming so quickly after vulnerabilities, there is no way to defend yourself without the ability to roll out protection in hours, not days, weeks or months. That window of exposure is much too long.
If Equifax applications were monitored for vulnerabilities by Contrast Assess, they would have been alerted of the vulnerability even before it was publicly known. For example, the Struts 2 vulnerability (CVE-2017-9805) showed up in the Contrast Assess Dashboard prior to the CVE announcement and looked like Figure 1.
Figure 1. Contrast Dashboard Displaying a Previously Unknown Deserialization
Vulnerability like the Struts 2 Deserialization Flaw CVE-2017-9805.
And, if Contrast Protect had been part of these applications, attempts to exploit either of these vulnerabilities would have been blocked as shown in Figure 2. Contrast instantly protects applications and APIs against a broad range of attacks, including both of the CVEs in Struts. In fact, Contrast’s protection blocks a broad range of deserialization and expression language injection exploits – even ones that have not yet been discovered.
Figure 2. Contrast Dashboard Displaying a Blocked Attempt to
Exploit the Struts 2 Expression Language Vulnerability, CVE-2017-5638.
It’s been a tough week for application security. It’s always disappointing to see large companies entrusted with the security of our PII, financial information, healthcare information, and other critical assets make mistakes.
It’s no surprise that web application attacks are the leading cause of large breaches by a very wide margin – over twice the next leading cause. The *average* web application or API has 26.7 serious vulnerabilities. That is a staggering, unbelievable number. And organizations often have hundreds, thousands, or even tens of thousands of applications.
Figure 3. The Average Application has a Staggering Number of Vulnerabilities.
We all have to do better. Contrast stands ready to help any organization that wants to lock down their application portfolio. We know scanners and firewalls from the early 2000s are frustrating. That’s why we created Contrast… a totally new and revolutionary approach to securing web applications from the inside.
I think the lesson from this week is that you have to secure your applications now. Any company could be the next Equifax.
~ Jeff Williams