It's hard to overstate what's happening here. The FBI, New York and Massachusetts Attorneys General, and Congress are now running inquiries into the Equifax breach. More will come. It's clear that the U.S. economy will change in some way as a result of this Struts 2 vulnerability. It may be macabre and indulgent, but you can’t help but to speculate on the consequences:
- Will we see the the death of Social Security Numbers?
- Will one of the "big three" major credit bureaus be dissolved?
- Will we get legislation around application security?
Whatever happens, I hope the world recognizes this is a watershed moment for software application security.
Let’s take a step back. If you weren't hacking in late 1990s and early 2000s, you missed a great time to be a hacker. Vulnerabilities in operating systems and their services were abundant with little or no IDS/IPS — there seemed to be a remote Linux exploit every week.
Now, 15 years later, I’ve got a theory as to why the well has run pretty dry on remote root exploits.
I don't think it was due to more secure APIs being made available, secure coding guidance or SDL changes, like we saw at Microsoft. I think it was system-level protections like:
- Data Execution Prevention (DEP) — which makes exploits harder to actuate
- Address Space Layout Randomization (ASLR) – which also makes exploits harder to actuate
- Automatic updates – used to rapidly deliver security fixes
These protections were instrumented in by the compiler and runtime, and provided built-in protections against common bug classes. The ability to continuously deliver security improvements to replace vulnerable code was a nice boon.
Those other things helped, but the tectonic movements were in the stack. I don’t think this is a controversial conclusion.
In the modern world, libraries and frameworks now constitute our application's "operating system." Do you use anything like DEP or ASLR or automatic updates for your applications? These application components are a part of the attack surface, and they're vulnerable — and most folks don't know the extent of it!
This is why in 2013 we recommended OWASP put "Insecure Dependencies" as one of their Top Ten risks, and why it was one of the first features of Contrast Assess. I don’t see people challenging this anymore – so this must not be controversial either.
Maybe there's some haphazard protections for some types of bug classes in your custom code. However, I'm 100% certain there's nothing in your custom code meant to stop attacks against your libraries. Anybody who's in application security for more than a few weeks knows that developers would laugh at the thought. They barely have time for the little security they do build in. Again, not controversial.
Okay, I've now said 3 uncontroversial things!
The upshot of those things is obvious – you absolutely need some protection against common bug classes in your application. And, you absolutely need a solution that delivers rapid responses against new threats to your applications, libraries and frameworks.
I'm not into shilling, but this problem is exactly what Contrast Protect was meant to solve. Our customers were protected from the Struts 2 CVE used in the Equifax attack within hours of the advisory being released. You can be too!