2014 - the infosec year in review - part 10 (the end)

This is part 10 of a 10 part blog series, discussing the things I found to be game changers in Infosec in 2014.  I have so much left that I could write about, but I have other things to get to so I'll cut this series off here.

Item:  ShellShock

What is (or was) it?  A vulnerability in the bash shell that the media struggled to understand and report on.

Why it's significant? Bash has an amazing number of features, too many in fact.  Does your shell need to be a full on programming language supporting functions?  Maybe so, maybe not.  Does your shell need to have a built in TCP server and client?  I'm going to say definitely not on this one.  But the fact is that bash is all this and more. 

The ShellShock vulnerability comes about because when a function is declared and assigned to an environment variable, bash executes anything after the end of the function definition as code.  This is not desired functionality and leads to arbitrary code execution.  There are an amazing number of libraries that call system() or use shell environment variables under the hood.  Many Apache libraries place things such as the User-Agent string in an environment variable.  If the User-Agent string is in fact a bash function definition and the server is vulnerable, we can in fact execute arbitrary code.

Could it have been prevented? Yes, this is really a case where feature creep was our undoing.  I love bash for its tab completion. As a pentester, I love that bash has a network server so I don't have to rely on netcat.  But wow, we have to be sensible about features, especially in something as prolific as the default shell on most *nix installations.

At Rendition Infosec, we've found that a lot of our customers don't understand the severity of the ShellShock bug.  I personally think that people in infosec have been overwhelmed this year by Heartbleed and a ton of other "must patch this now" bugs.  I've had some customers tell me that ShellShock is no worse than Heartbleed.  I personally disagree.  Heartbleed was an information disclosure vulnerability with a low chance of disclosing the most sensitive information (server private key).  But ShellShock is a remote code execution vulnerability that works reliably against vulnerable targets. Put bluntly, it's a game changer.

There are also far more devices vulnerable to ShellShock.  We have many embedded devices that run bash (I admit that most run ash as their default shell).  Many of these embedded devices are no longer receiving updates.  I still find MS08-067 in penetration tests today, years later (though I admit that it's becoming increasingly rare).  For these devices that aren't easily upgraded (requiring new firmware, etc.) the outlook is much more bleak.

Closing the door
When I started the Infosec year in review, I figured it would be a 5 part series.  As I started looking for things to write about, I found more and more. In the end, it was hard to decide what subjects deserved time in this year of awesome breaches.  Thanks for reading up to this point and I look forward to a busier 2015 (and definitely one with more blogging).