Tag Archives: shellshock

The Shellshock Exploit


Yesterday afternoon, an exploit called Shellshock came to light on a security message board .  CVE-2014-6271, as it is called by National Vulnerability Database, allows a remote user to execute arbitrary or malicious commands on a remote server, such as those that host websites; it has been given the highest impact rating, 10, for this reason .


This exploit presents a tremendous risk reminiscent of Heartbleed, because it potentially impacts many thousands of websites and other servers on the internet. A vulnerable system would allow any remote, unauthenticated user to run commands on the server, potentially allowing them to perform malicious activities: phishing, stealing data, installing a rootkit, etc.

Vulnerable Systems

Any system running Bash up to version 4.3 is potentially vulnerable, which includes Linux, Unix, and Mac OS X operating systems . The main avenue for remote exploitation of this bug is via websites served by CGI, which is a common mechanism for providing applications powered by PHP, Perl, Python, or many other languages.

Already there have been multiple reports of this exploit being used in the wild , so it is vital to examine your own environment for any unix-like systems that have Bash installed, and to apply vendor-provided patches where applicable.

You can use this tool to attempt to determine if your website is vulnerable, use the newly-available metasploit module , or run this command from a terminal on your Linux/Unix machines:

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If this command returns “vulnerable”, then you are vulnerable to CVE-2014-6271 and should patch your system immediately! If you run this:

env X='() { (a)=>\’ sh -c “echo date”; cat echo

And the date prints out, then you are vulnerable to CVE-2014-7169 and should attempt to patch, or sit tight until your vendor releases one, using other mitigation techniques in the short-term until such a patch is available. Currently, Debian, Ubuntu, RedHat, Gentoo, Slackware, and Suse have fixes or patches available.


Here at ESP, we’ve mostly been spared – as with Heartbleed – because our applications are primarily written in ASP.NET, and hosted in an environment that lacks any installation of Bash. Additionally, our auxiliary web servers run PHP via a module rather than CGI, which is required in most instances for remote exploitation of the bug; these servers were patched after our vendor provided updates to address the flaw.


There are several ways to mitigate this vulnerability in your own environment. Some of these avenues are listed below, along with a short explanation.

Patch pertinent systems

The easiest and most vital solution is to apply patches to any systems that you can determine are affected by Shellshock. On Debian systems, for example, this can be as simple as running “apt-get update; apt-get upgrade” in the terminal. The first available patches did no fully mitigate all attack strategies , so a second update may be required; the particular ID associated with the incomplete patch is CVE-2014-7169, and updates addressing that vulnerability have been released by several major vendors . There may be a possibility new variants of the attack, so keep checking over the course of the next several weeks and apply any superseding updates. Ask your vendors if any of their software is vulnerable and/or needs to be patched.

Use mod_php

For this vulnerability, because remote exploitation of websites requires that they be served via CGI, you could potentially mitigate Shellshock by serving your site with a module or a different form of CGI instead; if you use Apache, you can use mod_php as a temporary measure, for example. Whether socket-based CGI applications (e.g., php-fpm with nginx) are vulnerable is still being investigated , but mod_php should be safer, if you make sure that your code does not call Bash in any way that a user can alter.

Use alternate shells

Another temporary mitigation strategy is to uninstall Bash, and use a different shell as default, such as Dash .

Use firewall rules

Since this bug can affect web servers as well as OpenSSH servers, you should examine your firewall rules to make sure that only necessary sites/services are exposed to the internet. If a server is for internal use and has no business-case for being available externally, block access to it.

Further Reading