The Shellshock vulnerability is present in the Bourne Again Shell (Bash) versions up to and including 4.3. Bash is a popular command shell for Unix and Linux operating systems, and it is often the default shell for many platforms, including OSX.

The version of Bash can be easily be identified by using the bash –version command.

# bash --version
GNU bash, version 4.2.37(1)-release (i486-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This vulnerability is actually quite simple and easy to understand. Bash allows functions to be defined in environment variables and processes such functions when a session is initiated. However, the processing does not stop at the end of the function definition, like it should, but it instead continues to process subsequent commands in the string.

Consider the following environment variable. The blue text is a standard function definition, and the red text contains two additional commands. These commands will print (echo) the word “Vulnerable” to the screen, as well as print the id of the current user. Note that commands are separated by semicolons (“;”).

DEMO="() { ignored; }; echo Vulnerable; /usr/bin/id"

This environment variable can be defined using the export command.

# export DEMO="() { ignored; }; echo Vulnerable; /usr/bin/id"

This alone does not trigger the vulnerability. However, the env command can be used to list the environment variables and confirm that this new variable has indeed been defined.

# env
DEMO=() { ignored; }; echo Vulnerable; /usr/bin/id

Now, if a new Bash session is started, the word “Vulnerable” and the current user ID information are displayed, as expected.

# bash
uid=0(root) gid=0(root) groups=0(root)

The primary attack vector for remote exploitation is currently Apache web servers that are hosting CGI applications. This is due to the fact that this configuration, as denoted in the CGI specification, allows environment variables to be created from user-controlled input. Several avenues for defining custom environment variables exist, but HTTP headers are the most straightforward.

The following example is a standard HTTP GET request that contains a custom header (Demo), which includes a function definition and additional id command.

GET /cgi-bin/test.cgi HTTP/1.1
Host: localhost
Accept-Encoding: identity
Demo: () { ignored;}; /usr/bin/id
Content-type: application/x-www-form-urlencoded

Submitting this request to a CGI script hosted by Apache creates the following environment variable.

HTTP_DEMO="() { ignored;}; /usr/bin/id"

Again, simply defining the environment variable does not result in automatic code execution. The underlying CGI script must meet specific conditions as well. Consider the following CGI script. This script simply executes the ifconfig command (which would display network interface information if returned to the user). This script is not vulnerable to attack.

print "Content-type: text/html\n\n";

However, the following script effectively executes the same command, but it first initiates a new Bash session. This script is therefore vulnerable.

print "Content-type: text/html\n\n";
exec('/bin/bash -c ifconfig');


The impact of successful exploitation will vary considerably based on the target host. Configurations that are properly hardened will suffer less immediate impact than those that are not. For example, exploiting the previous CGI script on a current, default Apache installation only results in a compromise of the limited www-data user, as shown below.

$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Granted, any level of access is concerning. Even an unprivileged account may be used to obtain sensitive data or fully compromise the system through privilege escalation attacks. However, such a scenario is still far preferable over directly facilitating a full system compromise.

While the above demonstration is currently the most likely attack vector, any service that both allows users to define environment variables and initiates additional Bash sessions is vulnerable to attack. Proof-of-concept exploits are already starting to surface for other services, such as DHCP.


As one can imagine, the attack vectors for this vulnerability are numerous. Because this flaw is so tightly linked to the underlying operating system, any Unix or Linux service that runs in a Bash environment is potentially vulnerable. However, identifying vulnerable systems on your own is also trivial. In addition to basic version checks, as shown in the first command excerpt, you can simply open a shell and run the following command (Vulnerable systems will print the word “Vulnerable” to the display):

# env SHELLSHOCK="() { :;} ; echo Vulnerable" /bin/bash -c test

Detection methods, remediation procedures, and exploitation prevention signatures are all in various stages of development, with many vendors already developing and releasing patches. While opening a shell on every Unix/Linux-based network host you’re responsible for may not be feasible, the immediate priority should revolve around identifying accessible Unix/Linux services and conducting further analysis. Public-facing services should be reviewed first, given their significantly greater exposure, with a review of internal services occurring as time and resources allow.

The following two commands will provide an initial list of common Unix, Linux, and OS X/Mac services that are accessible on the specified network range(s), and the underlying host’s operating system should be reviewed for the presence of this vulnerability.

# nmap --open -oG shellshock.gnmap -sV -O <network range(s)>
# grep –i "linux\|unix\|os x\|mac" shellshock.gnmap

You can use virtually any scanner to search for this vulnerability on your network, or write your own based on version or echo checks, but vendors such as Tenable, Rapid7, and Qualys have already rolled out updates to support detection of vulnerable systems.


The most effective remediation strategy obviously consists of applying patches to affected systems. Patches already exist for most Linux distributions, such as Red Hat and Debian. As of this writing, OSX v10.9.5 and earlier are vulnerable, and Apple has not provided any information regarding when a patch will be available. However, an immediate workaround does exist, if one is willing to manually recompile Bash on OSX. If the system or device does not allow operating system patches to be applied directly, contact the vendor for such a vulnerable host in order to obtain specific remediation instructions. While Linux is commonly used across a wide range of systems and devices, limited administrative functionality may require firmware updates or other custom remediation procedures.

This vulnerability also presents an opportunity to review systems for unnecessary or unhardened services, such as FTP, Telnet, SSH, HTTP/S, and DHCP. While some services will undoubtedly be immune to this attack, obscure attack vectors will likely continue to surface for the foreseeable future, and a service shouldn’t be considered secure simply because a proof-of-concept exploitation technique doesn’t currently exist.

Unnecessary services should be disabled (or restricted via firewall access-control lists, at a minimum) in order to reduce a host’s overall attack surface. Furthermore, services that must remain accessible should be hardened as much as possible. For example, triggering this condition via SSH requires valid credentials, and implementing keys-based authentication will reduce associated risks further than traditional password-based authentication.

Prevention capabilities will evolve as additional exploits are made public or discovered in the wild. As mentioned earlier, the most likely attack vector is currently via Apache mod_cgi scripts. This is evident by the fact that several proof-of-concept CGI exploits have already surfaced on the web, and a corresponding Metasploit exploit module has also already been developed. However, the defensive side is moving just as fast, and this CGI-based attack vector can be mitigated with mod_security rules published by Red Hat, F5 LineRate (of course, there’s an F5 BIG-IP iRule as well), and Cisco has also updated their signatures to detect and block these attacks. Contact your security control vendors for further information regarding their options for attack prevention.

Finally, be advised that many embedded systems and other devices, including but not limited to printers, security cameras, environmental monitoring solutions, SOHO routers and switches, Network Attached Storage (NAS) devices, and many types of consumer electronics are likely susceptible to this vulnerability as well. Furthermore, these devices could be difficult or even impossible to patch, and as detailed above, access to network services should be disabled or restricted at the bare minimum.

Consumers should be on the lookout for firmware updates from the manufacturers of these devices, and the device and perimeter network configuration should be reviewed to determine which, if any, services are directly exposed to the Internet. Publicly-accessible services in particular should be disabled or restricted in order to avoid exploitation. These random, Internet-accessible devices may pose the largest threat, as they are easy to overlook and may remain accessible and vulnerable for extended periods of time. Research is already underway to convert proof-of-concept exploits into self-propagating worms.


For additional information on this subject and the opportunity to ask questions, please click here to register for our Webinar titled:  How Shocking is ‘Shellshock?’, occurring on Sept. 29th, 2pm (EDT).


About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.