It has been barely 6 months since the Heartbleed vulnerability was revealed, but just as the global security community has recovered from this vulnerability, one that is more prevalent – and potentially far more damaging – has emerged. The Shellshock vulnerability exploits a weakness in the Bourne Again SHell (BASH) that is native to (and often the default for) many Unix derivatives across the globe. While the extent of the damage has yet to be determined, it is highly likely that any services running on a Unix distribution are exposed.

While many are proclaiming that “the sky is falling,” it isn’t quite that bad. Certainly, the exploit can cause considerable damage for any organization that is exposed – becoming a botnet drone would be bad for PR, as would having your administrator privileges revoked on your own commerce server. Where possible, administrators should review current security policies. But what is key here is an understanding of this exploit’s vectors of attack, all of which take advantage of the script or commands that call BASH itself. By manipulating the command string that calls the shell, attackers are able to execute many privileged actions as though they were logged in with administrative access. Some of the applications most susceptible to the attack include Unix mail applications (the back-end applications often rely on BASH), dhclient dependents, and Apache Tomcat. Also susceptible are custom web applications that have script access from a web site (cgi-bin in particular). The list is growing and currently includes HTTP, FTP, mail, VoIP, DHCP, MySQL. Some of the early activity shows hackers exploiting the shell to drop a remote system transfer, executing the package locally (in most cases to install a botnet agent), and then deleting the transferred file to remove all trace of the local execution.

Security teams should patch susceptible systems; be vigilant for indicators of compromise (for example, an unusual increase in site traffic or unusual source/destination information); and monitor logs for unusual behavior. Ensure that log monitors are set up correctly – by enabling debug logging on your web server, all transactions on the server will be visible, as opposed to the more limited set of logs that is enabled by default.

There are many security solutions currently available that help to detect and prevent such attacks. Note however that these solutions are updated frequently (for example, new intrusion prevention system [IPS] signatures, and updates to web application firewall [WAF] policies and breach detection systems [BDS]), and security practitioners should ensure that they have the latest updates.

If Chicken Little had a security product, it would be a WAF.