10/01/2014 Updates:

• Shellshock: Vulnerable Systems you may have missed and how to move forward
• VMware Begins to Patch Bash Issues Across Product Line
• Honeypot Snares Two Bots Exploiting Bash Vulnerability

Updated (9/29/2014):

• PowerCLI script for checking VMWare systems.for BashBug vulnerability
• ShellShock webscanner
• Dark Reading: New BashBug vulnerabilities surface
• Dark Reading: Making Sense of ShellShock Chaos
• Rapid7’s updated blog post
• TrustedSec: ShellShock DHCP Exploit Proof of Concept
• ShellShock Early Exploit Methods
• How to Make Mac OSX Vulnerable to BashBug/ShellShock
• Install the Mac OSX Patch
• TrendMicro’s ShellShock Blog Series

• Wikipedia entry for ShellShock/BashBug

Overview
This is a “game-over” type of vulnerability due to the ubiquity of bash on *nix systems.

Fixing it involves recompiling bash or downloading a patched version from the OS vendor/provider.

It’s easy to attack and there is no authentication required when exploiting Bash via CGI scripts.
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

“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.”
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

“Trend Micro describes this vulnerability as “plague-like,” dwarfing Heartbleed, and hitting “approximately a half-billion Web servers and other Internet-connected devices.” Shellshock gives attackers command access to Linux- and UNIX-based systems that use Bash. Therefore, industry experts say, there are a huge number of potential attack vectors — Mac OSX devices, Android devices, OpenBSD, DHCP clients, SSH servers, web servers using CGI or Apache (including hosting servers), home routers, Bitcoin Core, and embedded systems in other Internet of Things objects like medical devices, digital cameras, and televisions.”
http://www.darkreading.com/shellshock-bash-bug-impacts-basically-everything-exploits-appear-in-wild/d/d-id/1316064?_mc=sm_dr

Vulnerable Systems & Patches:
“The vulnerability affects versions 1.14 through 4.3 of GNU Bash. Patches have been issued by many of the major Linux distribution vendors for affected versions, including:

• Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
• CentOS (versions 5 through 7)
• Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
• Debian
• Mac OS X

Akamai is patched: https://blogs.akamai.com/2014/09/environment-bashing.html

VMWare is looking into it: http://blogs.vmware.com/security/2014/09/vmware-investigating-bash-command-injection-vulnerability-aka-shell-shock-cve-2014-6271-cve-2014-7169.html

F5 BIG-IP is not known to be vulnerable, but is patching anyway:  https://devcentral.f5.com/articles/cve-2014-6271-shellshocked

How to manually patch Apple Bash

http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851

Lots and lots of *nix systems are vulnerable: http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

Remediation:

Remediation is obviously going to be most successful by applying patches to affected systems. Check with relevant vendors for updated information. This is also an opportunity to review systems for unused services, like FTP, Telnet, and DCHPd, and disable them when they are not required. As of writing, there is no word on a patch for OSX, but a workaround exists if one is willing to recompile Bash on vulnerable OSX systems.

Prevention capabilities will evolve as various exploits are made public or discovered in the wild. As of writing, the most critical attack vector is via Apache mod_cgi scripts, as several working exploits can be found on the web, and a Metasploit module has already been developed to exploit it. This attack vector can be mitigated with mod_security rules published by Red Hat, F5 LineRate, of course there’s an F5 BIG-IP iRule for that, and Cisco has updated signatures to detect and block attacks.

Finally, be advised that many embedded systems like SOHO routers and consumer electronics like Network Attached Storage (NAS) devices are likely vulnerable. Further, these devices could be difficult or even impossible to patch. Consumers should be on the lookout for firmware updates from manufacturers of these devices, and if NAS or router administration interfaces are connected to the Internet, they should be disconnected to avoid exploitation. These connected devices likely pose the biggest threat, as research is already underway to convert exploits into self-propagating worms.
http://www.guidepointsecurity.com/940/vulnerability-management/how-shocking-is-shellshock/

Checking Your Systems:

Scanning systems by sending a http header with code in it to a vulnerable system running a web server may run arbitrary code. This is bad!

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

A shellshock worm is just a matter of time…
http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html

MetaSploit has a module for finding & ultimately exploiting this bug:  https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271

Run this commands to test Bash:
$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If you see an error, you are probably safe. If you see vulnerable this is a test”, you are vulnerable.

Technical Detail:

Rapid 7 posted a video describing “How Does Bashbug (AKA shellshock) Work?  How Do I Remediate?”

“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:

• 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 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“
https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271

“Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes.  Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment.  The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition. 
For example, an environment variable setting of
  VAR=() { ignored; }; /bin/id
will execute /bin/id when the environment is imported into the bash process.  (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.)

The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.

So far, HTTP requests to CGI scripts have been identified as the major attack vector.

A typical HTTP request looks like this:

GET /path?query-param-name=query-param-value HTTP/1.1
Host: www.example.com
Custom: custom-header-value

The CGI specification maps all parts to environment variables.  With Apache httpd, the magic string “() {” can appear in these places:

* Host (“www.example.com”, as REMOTE_HOST)
* Header value (“custom-header-value”, as HTTP_CUSTOM in this example)
* Server protocol (“HTTP/1.1”, as SERVER_PROTOCOL)

The user name embedded in an Authorization header could be a vector as well, but the corresponding REMOTE_USER variable is only set if the user name corresponds to a known account according to the
authentication configuration, and a configuration which accepts the magic string appears somewhat unlikely.

In addition, with other CGI implementations, the request method (“GET”), path (“/path”) and query string
(“query-param-name=query-param-value”) may be vectors, and it is conceivable for “query-param-value” as well, and perhaps even “query-param-name”.

The other vector is OpenSSH, either through AcceptEnv variables, TERM or SSH_ORIGINAL_COMMAND.

Other vectors involving different environment variable set by additional programs are expected.”
http://seclists.org/oss-sec/2014/q3/650

“In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the bash shell. It is common for a lot of programs to run bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

• ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
• Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
• PHP scripts executed with mod_php are not affected even if they spawn subshells.
• DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
• Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
• Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Like “real” programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:

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

The patch used to fix this flaw, ensures that no code is allowed after the end of a bash function. So if you run the above example with the patched version of bash, you should get an output similar to:

 $ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x’
 this is a test
”
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

Looks like the original patch is incomplete:
“Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169. Red Hat is working on patches in conjunction with the upstream developers as a critical priority.”
https://access.redhat.com/articles/1200223

Red Hat’s review of how this affects common configurations:

https://access.redhat.com/articles/1200223

References:

• GuidePoint Security write-up on BashBug
• ShellCode: Everything you need to know
• NIST CVDE Info
• ErrataSec: Scanning the Internet for ShellShock
• ErrataSec: ShellShock bug is Wormable
• Rapid7: Bash-ing into the network
• Seclist post on Bashbug
• RedHat writeup on the Bash Vulnerability
• More info from RedHat
• Akamai write-up on BashBug/ShellShock
• SANS write-up on Bash vulnerability
• Dark Reading write-up on Bash vulnerability exploits in the wild
• Rapid 7 video describing “How Does Bashbug (AKA shellshock) Work?  How Do I Remediate?”