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 today, 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 fix is being tracked as CVE-2014-7169.
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.
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:
1) Diagnostic CGI scripts that are written in Bash or call out to system() where Bash is the default shell
2) 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 exploit it are fairly uncommon for remote exploitation.
Update: A DDoS bot that exploits this issue has already been found in the wild by @yinettesys
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.
How can you protect yourself?
The most straightforward answer is to deploy the patches that have been released as soon as possible. Even though CVE-2014-6271 is not a complete fix, the patched packages are more complicated to exploit. We expect to see new packages arrive to address CVE-2014-7169 in the near future. If you have systems that cannot be patched (for example systems that are End-of-Life), it’s critical that they are protected behind a firewall. A big one. And test whether that firewall is secure.
What can we do to help?
Rapid7's Nexpose and Metasploit products have been updated to assist with the detection and verification of these issues. Nexpose has been updated to check for CVE-2014-6271 via credentialed scans and will be updated again soon to cover the new packages released for CVE-2014-7169. Metasploit added a module to the framework a few hours ago and it will become available in both Metasploit Community and Metasploit Pro in our weekly update. We strongly recommend that you test your systems as soon as possible and deploy any necessary mitigations. If you would like some advice on how to handle this situation, our Services team can help
Update
A bug discovered in the widely used Bash command interpreter poses a critical security risk to Unix and Linux systems – and, thanks to their ubiquity, the internet at large.
It lands countless websites, servers, PCs, OS X Macs, various home routers, and more, in danger of hijacking by hackers.
The vulnerability is present in Bash up to and including version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise: CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts – are vulnerable to remote-code injection. OpenSSH and some DHCP clients are also affected on machines that use Bash.
Ubuntu and other Debian-derived systems that use Dash exclusively are not at risk – Dash isn't vulnerable, but busted versions of Bash may well be present on the systems anyway. It's essential you check the shell interpreters you're using, and any Bash packages you have installed, and patch if necessary.
"Holy cow. There are a lot of .mil and .gov sites that are going to get owned," security expert Kenn White said on Wednesday in reaction to the disclosed flaw.
The 22-year-old bug, dating back to version 1.13, lies in Bash's handling of environment variables: when assigning a function to a variable, trailing code in the function definition will be executed, leaving the door wide open for code-injection attacks. The vulnerability is exploitable remotely if code can be smuggled into environment variables sent over the network – and it's surprisingly easy to do so.
According to the NIST vulnerability database, which rates the flaw 10 out of 10 in terms of severity:
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
An advisory from Akamai explains the problem in more depth, as does this OSS-Sec mailing list post.
Proof-of-concept code for exploiting Bash-using CGI scripts to run code with the same privileges as the web server is already floating around the web. A simple Wget fetch can trigger the bug on a vulnerable system.
A nasty bug in many of the world’s Linux and Unix operating systems could allow malicious hackers to create a computer worm that wreaks havoc on machines across the globe, security experts say.
The flaw, called Shellshock, is being compared to last spring’s Heartbleed bug because it lets attackers do some nasty stuff—in this case, run unauthorized code—on a large number of Linux computer servers. The flaw lies in Bash, a standard Unix program that’s used to connect with the computer’s operating system.
The good news is that it doesn’t take long to patch the bug. At internet infrastructure provider CloudFlare, admins scrambled for about an hour this morning to fix the flaw, which was disclosed late on Tuesday. “We got 95 percent of it done within 10 minutes,” says Ryan Lackey a security engineer at the company.
The flaw is being compared to last spring’s Heartbleed bug because it lets attackers do some nasty stuff on a large number of Linux servers
Because Shellshock is easy to exploit—it only takes about three lines of code to attack a vulnerable server—Lackey and other security experts think there’s a pretty good chance that someone will write a worm code that will jump from vulnerable system to vulnerable system, creating hassles for the world’s system administrators. “People are already exploiting it in the wild manually, so a worm is a natural outgrowth of that,” Lackey says.
To exploit the bug, the bad guys need to connect to software such as PHP or DHCP—which use bash to launch programs within the server’s operating system
I'm at the Virus Bulletin 2014 Conference, taking bets on when we'll see a worm exploiting the #Shellshock bash bug.
— Mikko Hypponen (@mikko) September 25, 2014
There are still some important questions about the bug. One is whether other operating systems that use Bash—Mac OS, for example—are vulnerable. Another big one: how many linux server applications and appliance-like Linux devices—things like storage servers or video recording devices—might be vulnerable to the flaw. Many of these Linux systems to not use the Bash software, but those that do could be vulnerable to attack and difficult to patch.
In the grand scheme of things, Shellshock is not as big of a problem as, say, phishing attacks, which continue to trick internet users, says Robert Graham, CEO of Errata Security. However, it’s “slightly worse then Heartbleed,” he says. “It’s in more systems. It’s going to be harder to track them down and patch them, and you can immediately exploit it with remote code execution.” Heartbleed let criminals steal your username and passwords, but it didn’t make it quite so easy to run your own malicious software on a vulnerable system, Graham says.
Like Heartbleed, the new bug has been around for a long time, and was introduced in a widely used piece of open source software. In the wake of Heartbleed, the open source community came up with some money to beef up the security of several popular open-source tools. And it may be time to add a few more—including Bash— to that list.
Exploiting the BUG
This article has a nice example of exploiting this bug:
Exploiting the Bug
By creating a HTTP request like this:
Code[select]
target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74 The attacker is able to (in this situation) have the target ping a
specific IP. Imagine many targets doing this simultaneously to perform a DDOS attack as seen in the post below:
</DDOS> 
