Bash-ing Into Your Network – Investigating CVE-2014-6271

Blog Post created by jenellis Employee on Sep 25, 2014

[UPDATE September 29, 2014: Since our last update on this blog post, four new CVEs that track ShellShock/bash bug-related issues have been announced. A new patch was released on Saturday September 27 that addressed the more critical CVEs (CVE-2014-6277 and CVE-2014-6278).  In sum: If you applied the ShellShock-related patches before Saturday September 27, you likely need to apply this new patch. We have updated our original blog post below to reflect this new information.]

Original blog post with September 29 updates below:

By now, you may have heard about CVE-2014-6271, also known as the "bash bug", or even "Shell Shock", depending on where you get your news. This vulnerability was discovered by Stephane Chazelas of Akamai and is potentially a big deal.  It’s rated the maximum CVSS score of 10 for impact and ease of exploitability. The affected software, Bash (the Bourne Again SHell), is present on most Linux, BSD, and Unix-like systems, including Mac OS X. New packages were released September 25, but further investigation made it clear that the patched version may still be exploitable, and at the very least can be crashed due to a null pointer exception. The incomplete fixes are being tracked as CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, and CVE-2014-6278.


Should I panic?

The vulnerability looks pretty awful at first glance, but most systems with Bash installed will NOT be remotely exploitable as a result of this issue. In order to exploit this flaw, an attacker would need the ability to send a malicious environment variable to a program interacting with the network and this program would have to be implemented in Bash, or spawn a sub-command using Bash. The Red Hat blog post goes into detail on the conditions required for a remote attack. The most commonly exposed vector is likely going to be legacy web applications that use the standard CGI implementation. On multi-user systems, setuid applications that spawn "safe" commands on behalf of the user may also be subverted using this flaw. Successful exploitation of this vulnerability would allow an attacker to execute arbitrary system commands at a privilege level equivalent to the affected process.

What is vulnerable?

This attack revolves around Bash itself, and not a particular application, so the paths to exploitation are complex and varied. So far, the Metasploit team has been focusing on the web-based vectors since those seem to be the most likely avenues of attack. Standard CGI applications accept a number of parameters from the user, including the browser's user agent string, and store these in the process environment before executing the application. A CGI application that is written in Bash or calls system() or popen() is likely to be vulnerable, assuming that the default shell is Bash.


Secure Shell (SSH) will also happily pass arbitrary environment variables to Bash, but this vector is only relevant when the attacker has valid SSH credentials, but is restricted to a limited environment or a specific command. The SSH vector is likely to affect source code management systems and the administrative command-line consoles of various network appliances (virtual or otherwise).


There are likely many other vectors (DHCP client scripts, etc), but they will depend on whether the default shell is Bash or an alternative such as Dash, Zsh, Ash, or Busybox, which are not affected by this issue. (There are Metasploit modules available validating this exploit path.)


Modern web frameworks are generally not going to be affected. Simpler web interfaces, like those you find on routers, switches, industrial control systems, and other network devices are unlikely to be affected either, as they either run proprietary operating systems, or they use Busybox or Ash as their default shell in order to conserve memory. A quick review of a approximately 50 firmware images from a variety of enterprise, industrial, and consumer devices turned up no instances where Bash was included in the filesystem. By contrast, a cursory review of a handful of virtual appliances had a 100% hit rate, but the web applications were not vulnerable due to how the web server was configured. As a counter-point, Digital Bond believes that quite a few ICS and SCADA systems include the vulnerable version of Bash, as outlined in their blog post. Robert Graham of Errata Security believes there is potential for a worm after he identified a few thousand vulnerable systems using Masscan. The esteemed Michal Zalewski also weighed in on the potential impact of this issue.


In summary, there just isn't enough information available to predict how many systems are potentially exploitable today.


The two most likely situations where this vulnerability will be exploited in the wild:

  • Diagnostic CGI scripts that are written in Bash or call out to system() where Bash is the default shell
  • PHP applications running in CGI mode that call out to system() and where Bash is the default shell

Bottom line: This bug is going to affect an unknowable number of products and systems, but the conditions to remotely exploit it are fairly uncommon for remote exploitation.


Update (September 25): A DDoS bot that exploits this issue has already been found in the wild by @yinettesys.


Update (September 29): 

  • There have been several reports of CVE-2014-6271 being exploited through worms.
  • There is Proof of Concept code to exploit DHCP found by Geoff Walton.
  • There have been memory corruption flaw in the Bash parser found by @taviso being tracked as CVE-2014-7186 and CVE-2014-7187.  We don’t expect to see exploit code immediately and it wouldn’t be applicable without specific targeting.
  • A couple new issues were found by Michal Zalewski (@lcamtuf) the first, CVE-2014-6277, permits remote code execution and requires a high level of expertise.  The second, CVE-2014-6278, is more severe as it allows remote code execution and doesn’t require a high level of expertise.  These two vulnerabilities have been resolved in upstream patches Ubuntu/RHEL/Debian that include Florian Weimer’s unofficial patch.


Is it as bad as Heartbleed?

There has been a great deal of debate on this in the community, and we’re not keen to jump on the “Heartbleed 2.0” bandwagon. The conclusion we reached is that some factors are worse, but the overall picture is less dire. This vulnerability enables attackers to not just steal confidential information as with Heartbleed, but also to take over the device or system and execute code remotely. From what we can tell, the vulnerability is most likely to affect a lot of systems, but it isn't clear which ones, or how difficult those systems will be to patch. The vulnerability is also incredibly easy to exploit. Put that together and you are looking at a lot of confusion and the potential for large-scale attacks.


BUT – and that’s a big but – per the above, there are a number of factors that need to be in play for a target to be susceptible to attack. Every affected application may be exploitable through a slightly different vector or have different requirements to reach the vulnerable code. This may significantly limit how widespread attacks will be in the wild. Heartbleed was much easier to conclusively test and the impact way more widespread.

What can we do to help?

[Updated October 1]

Rapid7 Metasploit has been updated to assist with the detection and verification of these issues. Modules for testing various exploitation paths are available in both Metasploit Community and Pro. We strongly recommend that you test your systems as soon as possible and deploy any necessary mitigations.

Rapid7 Nexpose has been updated with authenticated and remote checks for CVE-2014-6271 and CVE-2014-7169. Nexpose 5.10.12 improves the accuracy for the remote Shellshock (CVE-2014-6271) vulnerability check customers should update their Nexpose deployments to Nexpose 5.10.12.  Nexpose 5.10.13 added authenticated coverage has been added for CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, and CVE-2014-6278.


If you would like some advice on how to handle this situation, our Services team can help.

Are Rapid7’s solutions affected?

[Updated September 29]

Nexpose Virtual Appliances are provided with the Ubuntu distribution operating system, which has patches for both CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, and CVE-2014-7187. We've just updated the Nexpose Virtual Appliance Deployment Guide with the instructions to update the underlying Ubuntu OS. We recommend that you review the guide and apply the latest system patches that were released on September 27th.


More information

We've gathered all information we've published about BashBug right here: bashbug CVE-2014-6271 (shellshock): What is it? How to Remediate | Rapid7