Huge bash exploit CVE-2014-6271

[Qtx]

Original release date: 09/24/2014
Last revised: 09/24/2014
Source: US-CERT/NIST
Overview
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.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base Score: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 10.0

https://web.nvd.nist.gov/view/vuln/d...=CVE-2014-6271

This is very easy to exploit and there will be a ton of hacked webservers among other things hacked in the next few weeks due to it. If you run a seedbox with certain settings there is a good chance you are vulnerable to this, it's not just an ssh issue. Also hardware with embedded linux may have issues. Also affects DHCP/network manager in some linux installs.

Various exploits are already out there and are so easy a 5 year old could do it.

It's bad.

[qasdfdsaq]

But they would still have to have some way to spawn a Bash shell in the first place (i.e. have shell access) right? Seeing as SSH won't execute any commands or even provide an environment prior to authentication... Yet the CVE says authentication not required.

[Edit]
Yep: " Regular use of OpenSSH is not affected because users already have shell access.". It's only if you limit shell access purely via executing a command in a shell, which isn't really a good way of doing it to begin with (Amazon uses it to prevent root access though).

Most embedded systems (well, all embedded systems I use) run a Busybox shell rather than Bash so it shouldn't be much of an issue there, mostly concerned about Apache + mod_cgi exploits. Especially if someone has a leaky php shell open.

[Qtx]

Originally Posted by qasdfdsaq

But they would still have to have some way to spawn a Bash shell in the first place (i.e. have shell access) right? Seeing as SSH won't execute any commands or even provide an environment prior to authentication... Yet the CVE says authentication not required.

Don't need to already have shell access. You can do it through a a http request and spawn a remote shell.

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)

Can also be abused via a rogue DHCP server to exploit some linux distros and also apple macs. It's not just mod_cgi.

[Osem]

Does any of this have implications for us ordinary folks using PCs for a bit of surfing etc.? If so how and what, if anything, can we do about it? Presumably some of the sites we access might be vulnerable but how might that affect us? The brief BBC article on this mentioned home users looking out for device updates on things such as routers but how would we do this in practice and what devices are vulnerable?

TIA

[qasdfdsaq]

Originally Posted by Qtx

Don't need to already have shell access. You can do it through a a http request and spawn a remote shell.

Guess that's another good example of why you should always run your web server processes in a deprivileged account...

Nonetheless the original source linked from your NIST article:

https://securityblog.redhat.com/2014...ection-attack/

says the vulnerability can be exploited via:

• 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)

But:

• PHP scripts executed with mod_php are not affected even if they spawn subshells.

So I fail to see how else it could be exploited via HTTP, if your process can't execute or spawn shells to begin with...


Ah well, I guess I'll have to keep reading up on this... Makes my job fun.

Can also be abused via a rogue DHCP server to exploit some linux distros and also apple macs. It's not just mod_cgi.

---------- Post added at 13:57 ---------- Previous post was at 13:56 ----------

Originally Posted by Osem

Does any of this have implications for us ordinary folks using PCs for a bit of surfing etc.? If so how and what, if anything, can we do about it? Presumably some of the sites we access might be vulnerable but how might that affect us? The brief BBC article on this mentioned home users looking out for device updates on things such as routers but how would we do this in practice and what devices are vulnerable? TIA

If you're running Windows, it will not affect you at all.

If you're running Mac or Linux but don't run any servers, you should be fine as long as attackers don't have direct physical access to your home network. On a public hotspot you might have to worry...

[Osem]

Originally Posted by qasdfdsaq

Guess that's another good example of why you should always run your web server processes in a deprivileged account...

Nonetheless the original source linked from your NIST article:

https://securityblog.redhat.com/2014...ection-attack/

says the vulnerability can be exploited via:

• 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)

But:

• PHP scripts executed with mod_php are not affected even if they spawn subshells.

So I fail to see how else it could be exploited via HTTP, if your process can't execute or spawn shells to begin with...


Ah well, I guess I'll have to keep reading up on this... Makes my job fun.




---------- Post added at 13:57 ---------- Previous post was at 13:56 ----------


If you're running Windows, it will not affect you at all.

If you're running Mac or Linux but don't run any servers, you should be fine as long as attackers don't have direct physical access to your home network. On a public hotspot you might have to worry...

Makes a change.

TVM

[Qtx]

Originally Posted by qasdfdsaq

Guess that's another good example of why you should always run your web server processes in a deprivileged account...

Nonetheless the original source linked from your NIST article:

https://securityblog.redhat.com/2014...ection-attack/

says the vulnerability can be exploited via:

• 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)

But:

• PHP scripts executed with mod_php are not affected even if they spawn subshells.

So I fail to see how else it could be exploited via HTTP, if your process can't execute or spawn shells to begin with...

mod_php and mod_cgi are different

As you suggest, in many cases a privilege escalation exploit (ie kernel) will need to be used in conjunction to make proper use of it.

F5 Big IP firewalls have an issue with this but it appears you need access to the web interface to take advantage of it. https://twitter.com/securifybv/statu...172673/photo/1

---------- Post added at 15:07 ---------- Previous post was at 14:46 ----------

Already some infections due to this have been found. This exploit is used to download an ELF binary with a secondary exploit to get root privileges and then install DDoS software.

[qasdfdsaq]

Well it's certainly got people in a panic at work... Spent all day patching servers now I've got people writing in concerned that their desktops are 'vulnerable'

[Qtx]

You could be doing the same again tomorrow....it's looking like the patch doesn't actually fix it.

[qasdfdsaq]

Yeah I'm aware of that. Shouldn't really matter tomorrow. Everything's now either on auto-update or had Bash removed. Most systems already patched themselves at 6am this morning so whenever a 'proper' fix comes out I'd expect that to make it on there too.

[qasdfdsaq]

Yep. Ubuntu and Redhat both released fixes for the second bug around 6am this morning.

[Qtx]

Automatic updates in production environments

ISC has changed it's ThreatLevel/InfoCon to Yellow.

At the Storm Center, we are strict and judicious on moving the InfoCon status. We felt, after dialog, that Yellow is warranted in this case as we are seeing signs of worm/botnet activity. This combined with so many systems are impacted [worm], with no signs of letting up [met].

We will monitor this closely and relax InfoCon when the situation seems to be more stable.

[met] https://github.com/rapid7/metasploit...work/pull/3891
[worm] http://www.itnews.com.au/News/396197...-networks.aspx

First link is a nice metasploit module which acts as a DHCP, infecting machines that ask for an IP. All you have to do is attach the machine with it running on to a networkk...

Some of the ITV link:

Wopbot has so far launched a distributed denial of service attack against servers hosted by content delivery network Akamai, and is also aiming for other targets, according to Gentili.

"Analysing the malware sample in a sandbox, we saw that the malware has conducted a massive scan on the United States Department of Defence Internet Protocol address range on port 23 TCP or Telnet for brute force attack purposes," he said.

The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 million addresses.

Gentili said Tiger Security had contacted UK provider M247 and managed to get the wopbot botnet command and control system taken down from that network.

However, the botmaster server for wopbot - hosted by US network Datawagon - is still up and distributing malware, Gentili said.

[qasdfdsaq]

Originally Posted by Qtx

Automatic updates in production environments

Better than expecting end users to do their own updates.

ISC has changed it's ThreatLevel/InfoCon to Yellow. First link is a nice metasploit module which acts as a DHCP, infecting machines that ask for an IP. All you have to do is attach the machine with it running on to a networkk... Some of the ITV link:

Wouldn't work on a decent corporate network that had DHCP snooping active. Quite easily exploitable on public hotspots though. However people have said elsewhere OS X's DHCP implementation is not vulnerable, nor is Windows for obvious reasons leaving just the small minority of Linux desktops (most servers I know would be on static addressing anyway).

---------- Post added at 01:34 ---------- Previous post was at 01:28 ----------

* Although I know and have worked with a good number of corporate networks vulnerable to all sorts of DHCP based attack, if you can set up a rogue DHCP server you can already intercept and modify all (non SSL) traffic on that network anyway, which gives you a far wider range of machines and vulnerabilities to attack if you just wanted a botnet.

[Qtx]

Ubuntu sent a third patch out:

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 14.04 LTS
- Ubuntu 12.04 LTS
- Ubuntu 10.04 LTS

Summary:

Several security issues were fixed in Bash.

Software Description:
- bash: GNU Bourne Again SHell

Details:

Florian Weimer and Todd Sabin discovered that the Bash parser incorrectly
handled memory. An attacker could possibly use this issue to bypass certain
environment restrictions and execute arbitrary code. (CVE-2014-7186,
CVE-2014-7187)

In addition, this update introduces a hardening measure which adds prefixes
and suffixes around environment variable names which contain shell
functions.

[qasdfdsaq]

Huh. Wonder when that came out, didn't get picked up by the auto-update this morning.