A killer vulnerability KILLS AGAIN!!! Another “branded vulnerability” – Shellshock – is heeeeere! Run for the hills, escape the planet, switch to a “secure OS” (Windows 3.1 fits the bill), stop the cyber, etc, etc, etc.
<insert all the obligatory World War I references to shell shock and jokes about being bashed by bash>
However, this post is not about Shellshock with a “perfect 10.0” in CVSS Base – at least not directly.
Sure, if you have not patched yet – stop reading this now. Deploy a patch to bash – focus the remediation on the Internet-visible servers first (some of our clients set a reasonable 1 hour patching timeline for this one – as in “patch all exposed systems within 1 hour of patch release.” Eat this, folks that take 90 days to patch!). Scan your servers for the vulnerability to know how exposed you are (if at all), and do not limit the scanning to the Internet-visible sites since having this issue on the internal servers makes the attacker’s job easier. Note that an authenticated scan will show that you are vulnerable on all Unix/Linux servers, but will NOT show where you are exploitable, while an unauthenticated scan will not show all the exploitation avenues (a great case study for the limits of modern VA technology). Some people have temporarily changed shells (tcsh is still alive!), thus breaking many scripts, and deployed NIPS and WAF rules tactically. Do all that, sure. Others have used this as an opportunity to remove the – frankly, idiotic! – shell scripts from public /cgi-bin directories and do other tightening of their infrastructure.
All in all, I think Shellshock is not even in the ballpark of Heartbleed (others disagree): with that baby, pretty much the entire SSL-using Internet was vulnerable and exploitable. Here with Shellshock we have a relatively small population of remotely exploitable systems (early evidence pointed at exploitable sites numbering in thousands, not millions). Sure, the impact (easy remote access by an attacker) is worse, but much fewer sites are exploitable.
But did I say this post is not about Shellshock? Ah, thanks for paying attention! It is not…
When I started being involved with infosec (which feels like a moment or an eternity ago, depending on the situation) by helping out with some Linux boxes at a small ISP, a wise mentor told me: Anton, don’t be stupid, don’t make your security solely dependent on not having any exploitable holes. Back then, IIS had dozens of exploitable remotes, while Apache was considered “secure” – and this is what we used. Still, the infrastructure was set-up in such a way that a remote exploit in Apache that gives you shell as “nobody” combined with one of many locals that escalates you to “root” meant “GAME OVER.” The attacker would have been able to destroy the entire business in about 20 minutes, for good [there were no offline backups – this is 1999 we are talking about]. So, that led to some major rethinking…
In any case, WHY IS THIS NEWS TO SOME PEOPLE NOW IN 2014?!!
So, as a reminder for most and as news for some: do not make your security architecture solely reliant on patching. Big vulnerabilities will happen and so will zero-days, so make sure that your entire security architecture does not crumble if there is one critical vulnerability: do defense in depth, layers, “least privilege”, controls not reliant on updates, monitoring, deception, etc. The fact that they have a 10.0 remote should NOT mean that you automatically lose everything!!
Miscellaneous fun posts:
- Security Essentials? Basics? Fundamentals? Bare Minimum?
- On “Defender’s Advantage”
- Security And/Or/Vs/Not Compliance?
- Bye-bye, Compliance Thinking. Welcome, Military Thinking!
Read Complimentary Relevant Research
How to Evaluate Cloud Service Provider Security
Security and risk management leaders continue to experience challenges to efficiently and reliably determine whether cloud service providers...
View Relevant Webinars
2017 CIO Agenda: A Security and Risk Management Perspective
The 2017 CIO Agenda highlights the importance of building a digital ecosystem for enterprises. Security and Risk Management leaders must...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.