Another Year, Another Critical Struts Flaw (CVE-2018-11776)

Will We Learn the Right Lesson This Time Around?

A little over a year ago, Equifax announced a huge breach of data that affected over 50% of all American adults. The data compromised was suitable for identity theft, but the identity of the attacker and their motive for stealing the data was never officially confirmed.

Now, another critical Struts vulnerability has emerged.

The fallout from last year’s critical Struts vulnerability, though widely covered by the media, didn’t always teach the right lesson. Equifax’s CEO was called before Congress and all but pinned it on an IT employee failing to patch Apache Struts. The patch was released over a month before the attack, but it’s common for large enterprises to require months to go through the full vulnerability discovery and patching process. Despite this, the clear message delivered by Equifax’s CEO and the media at large was, “you’ve got to patch faster than your adversary can attack.”

Unfortunately, that will be impossible in many cases. Let me explain.

Outpatching Attackers is a Fool’s Errand

In our annual State of Vulnerability Risk Management report for 2016, we released some research correlating attacks with patch release dates. The results were not encouraging for fans of the run faster than the bear crowd. We found that the vast majority of exploits are published the same day the vulnerability is published or earlier. While this doesn’t mean that every exploit is immediately being used in attacks, it does mean that patching alone won’t be an effective defense strategy. 

From the 2016 State of Vulnerability Risk Management report – this table presents the number of vulnerabilities with exploits published over various windows of time

Indeed, even the advice to just run faster than the slowest bear snack advice isn’t applicable here. Increasingly, attackers have become more comfortable with automation and orchestration than defenders. Particularly with vulnerabilities in web frameworks, attacks are likely to be automated and can be scripted to target all websites on the public Internet with minimal effort on the attackers’ part.

‘Drupalgeddon’, as it was termed in the media is a recent example of this. Drupal’s developers and maintainers stated anyone not patched within seven hours of the patch’s release should consider themselves compromised.

“Design systems as if there’s always a zero day and the patch is never coming”

You Can’t Install a Patch That Doesn’t Exist

As the previous chart shows, vulnerabilities are often exploited before vendors are aware of them. We call these ‘zero day’ vulnerabilities, or 0day (intentionally singular) for short. The best advice here is to design systems as if there’s always a zero day and the patch is never coming.

How can we protect against vulnerabilities that we don’t know about? Through detection, mitigation and hardening. Even the most serious vulnerabilities can be detected, prevented and stopped if systems are properly hardened and effective monitoring is in place.

Hardening

Often attacks only work because defaults are in place. Attackers and criminals depend on it. When you think about it, most, if not all malware authors and targeted attackers are blind to their targets – they’re counting on people using systems with many insecure defaults in place. Strategies like immutability, chroot jails and sandboxing can thwart successful exploits from going any further than that initial foothold. Some of the hardening guides from NIST, CIS, OWASP and DISA STIGs can be quite effective.

Mitigation

When vulnerabilities are discovered, but organizations know they can’t put a patch in place – at least, not immediately, mitigations might be an ideal short-term solution. Provided you already have WAF and IPS products in place, custom WAF/IPS rules can make excellent short-term ‘blockers’ for known vulnerabilities. Run-time application protection (RASP) products can stop many broad classes of attacks as well. Disabling unused or legacy services and protocols can mitigate attacks, which should be part of the hardening process. Famously, one of the mitigations for the NSA’s EternalBlue exploit (used by the WannaCry and NotPetya malware worms) was to disable SMBv1. In most organizations, this ancient protocol should have been disabled long ago.

Detection

Given enough time, eventually an attacker will succeed. Either an automated attack or a focused, human attacker will get through. This isn’t game over! No breach occurs at the moment of intrusion – with the exception of ransomware, it generally takes at least hours for an attacker to find, extract or pivot to what they’re looking for. If detected quickly, there is an opportunity to shut down the intrusion before damage is done. A commercial vendor, Capsule8*, makes a platform that is an excellent example of how this detection/containment process can be automated.

* We promise we’re not shilling for them, they’ve just built a good example of what we’re trying to describe! Yes, they’re also Brooklyn-based, but we also promise this is just coincidence!

Conclusion

It would be great to conclude this post with a bear metaphor, but vulnerabilities aren’t bears and bears aren’t vulnerabilities. Stay safe if you enjoy hiking in bear country.

Today, no company should be entirely dependent on a vendor patch. Everyone needs a strategy for handling both unknown vulnerabilities and known issues that can’t be patched or fixed right away. Also, we need to design our systems to be not just defensible, but resilient as well. If a single Struts vulnerability is all that stands between your company and a breach, you’ve got some work to do.