BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Now that the hype over the Shellshock vulnerability has settled, we can step back and get a clearer look at the exploit and its network security implications on the enterprise.
So why will Shellshock be so bad? In this tip, I'll discuss the impact Shellshock has had not only on network security, but also how incidents should be handled in the future.
Inside the Shellshock vulnerability
The Bourne-again shell or Bash has been the command processor (like the DOS command prompt on PCs) for popular Unix-based operating systems for the past 25 years. In late September of 2014, a flaw commonly referred to as Shellshock emerged on the heels of the headline-making Heartbleed OpenSSL flaw. Much like Heartbleed, this flaw left companies scrambling to release out-of-band patches to keep their products and users secure.
The Shellshock flaw, which turned out to be 20-plus years old, is a coding vulnerability that allows attackers to interpret text strings and run them as system commands. The specific exploit is carried out by injecting a Bash command into a webpage or similar script that's then executed via the vulnerable Bash interpreter. Essentially, anything that ran at a UNIX/Linux-based command prompt could be run on Shellshock-vulnerable systems. There's no filtering, nothing -- the command just executes. An attacker can tell the system to do whatever they want it to. Given what's at stake, this exploit can be especially problematic for critical network infrastructure systems.
How vendors responded to getting Shellshocked
In the typical discover-react-patch approach we've come to expect when such flaws are made public, vendors such as Cisco Systems Inc. and Juniper Networks Inc. quickly published their "fixes" to Shellshock. At first everything looked rosy, but it quickly became clear that the initial fixes didn't fully resolve the issue. As stated on the National Vulnerability Database website:
NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.
However, this isn't a reflection of the overall quality of these vendors' products; I think the issue goes much deeper than that. The discover-react-patch mode of operation is not an effective means for minimizing information risks, but then again there may not be a better solution. While the industry could try to push security deeper into the software development lifecycle, the reality is that human beings, computers and software are imperfect. As in the physical realm, unforeseen security issues are going to arise. The most important thing is what's being done after the notification of such flaws in order to minimize the impact it has on the network.
Defending against Shellshock
So what's the worst case scenario if the Shellshock vulnerability were ignored? It's pretty darn ugly. Since this flaw not only affects the command shell but also all software that interacts with it (for example, the Web servers, CGI scripts and other applications running on the system such as DHCP and OpenSSH), the security implications reach far and wide.
The main solution to fixing Shellshock-vulnerable equipment from Cisco and Juniper is applying the proper patches for CVE-2014-6271 or CVE-2014-7169. While this may seem easy enough, the real challenge enterprises have been facing is finding all the other systems that are vulnerable to Shellshock that are old, outdated and unsupported; these systems are proving to be most problematic.
Regardless of the platform, the good news is you still have some options to mitigate the risk of Shellshock -- and many other potential network security vulnerabilities -- by using network segmentation, firewalls and intrusion prevention, by disabling services or by even decommissioning the outdated systems altogether. If anything, perhaps Shellshock will help your IT department gain the support needed to upgrade its systems and implement better network security controls.
Learning from Shellshock
There's a saying that experience is something you don't get until just after you need it. This is true for most things. And the reality is that Shellshock is no different than the Melissa virus from 15 years ago or the Heartbleed flaw from months ago. There's no reason for well-run networks and information security programs to be fazed by this vulnerability. If supported and up-to-date systems are in use, periodic and consistent security assessments are being performed, and systems are being monitored and properly maintained, Shellshock -- and whatever is headed our way in the future -- should be a mere bump in the road.
While so many in our industry -- and those reporting sensationalized news -- try to stir the pot, the sky doesn't have to fall every time a critical vulnerability such as Shellshock is discovered.
Just don't wait until the next big vulnerability crops up to determine the worst case scenario; know your enterprise IT environment and maintain it properly. Invest money where it needs to be invested. Understand your business' specific risks now so that you can have the proper security controls and procedures in place to completely negate -- or least minimize the impact of -- whatever comes its way.
About the author:
Kevin Beaver is an information security consultant, writer, professional speaker and expert witness with Atlanta-based Principle Logic LLC. With over 25 years of experience in the industry, Kevin specializes in performing independent security vulnerability assessments of network systems, as well as Web and mobile applications. He has authored/co-authored 11 books on information security including the best-selling Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance. In addition, he's the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. You can reach Kevin through his website and follow him on Twitter at @kevinbeaver.
Don't miss the wave of shell security concerns Shellshock caused on social media
Get more info on the Bash vulnerability and open source security concerns