Slashdot Mirror
First Shellshock Botnet Attacking Akamai, US DoD Networks
Bismillah writes The Bash "Shellshock" bug is being used to spread malware to create a botnet, that's active and attacking Akamai and Department of Defense networks. "The 'wopbot' botnet is active and scanning the internet for vulnerable systems, including at the United States Department of Defence, chief executive of Italian security consultancy Tiger Security, Emanuele Gentili, told iTnews. 'We have found a botnet that runs on Linux servers, named “wopbot", that uses the Bash Shellshock bug to auto-infect other servers,' Gentili said."
Apache passes user-supplied content to CGI scripts as environment variables, so any CGI written in bash or that invokes bash (via system(), for example, on an OS that uses bash as /bin/sh) could be used as an exploit vector.
Rubbish. It certainly does not. It depends on inputs getting into environment variables which wind up eventually inside of bash. Which then goes "oh, look. code! I think I'll run that", and runs it.
Thanks bash.
Thash.
It's not the only botnet being constructed, see my comment here - already 653 exploited servers there right now.
/var/log/apache2/access*|egrep "};|}\s*;"
:;}; echo vulnerable' bash -c 'echo Testing...'
This is quite bad - as long as a bash CGI script is found by probing, exploiting only require putting a bash command in a header such as "Cookie:" for it to be executed. And this is only through HTTP - there are also aready other proof of concepts exploiting this through other bash-using services (DHCP servers for example).
You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):
grep cgi
And you can check if your bash is vulnerable using:
env x='() {
If 'vulnerable' appears, it is.
Well, Apache and literally every other CGI container since that's how CGI works: the HTTP environment (headers and various other stuff) is passed to the script being executed via specifically named environment variables.
You are in a maze of twisty little relative jumps, all alike.
Fix for CVE-2014-7169 was posted only a small bit ago:
http://www.openwall.com/lists/oss-security/2014/09/26/1
inputs getting into environment variables which wind up eventually inside of bash.
So we agree. Good-o.
No, you twit. Bash will read the environment variables sent to it by CGI, which populates the environment parameters before you can sanitise the inputs. By the time you're ready to begin parsing and sanitising, the damage is already (potentially) done.
The implications of this are far-reaching, and the only way to be reasonably secure is to patch the bash executable.
Crumb's Corollary: Never bring a knife to a bun fight.
Bash is an OS? You can uninstall bash and have everything run just as smooth with a replacement shell. Unlike a certain OS where you can't even remove a web browser and expect it to boot up ...
*DrugCheese rants*
but if you don't do something stupid like eval your those environment variables it doesn't turn into such a mess.
Your CGI script doesn't need to do anything at all. The rogue code injected into the env. variables is parsed and executed by bash when it sets-up the environment for your script.
Didn't I just say that? You'd have to explicitly invoke #!/bin/bash. I know of very few scripts that do that; most use #!/bin/sh.
Well, on my Debian unstable machine:
# find / -mount -type f | while read x ; do if [ "`head -1 $x | grep '^#\!/bin/bash'`" ]; then echo $x; fi; done 2>/dev/null
Ugly.
There are other vectors - in fact, any place that the website code (be it C, PHP, Java, Perl, whatever) runs another program *via* the shell. It depends on the language as to how this can happen. In perl, if you don't specify the full path to the thing you're calling, and you don't use a list for each argument then it'll go via the shell as a helper to make it do what you want. Obviously, anywhere you've called something as "sh -c /some/path/thing", then you're also going via the shell.
Simply calling something via the shell (or calling a shell script) isn't enough - you also need to pass some environment variables populated with user input. This seems incredibly unlikely except in CGIs. In most cases, you'd probably pass some command line arguments (maybe from user input), and you might statically set an environment variable or two (perhaps for a password or something). Those aren't a problem - it's only user input.
For anyone running CGI, you're most likely at risk. For anyone not doing so, you're probably not at risk, but code review will tell you for sure. This is no heartbleed (as the media seem to be making out), but it's pretty serious for anyone vulnerable.
As for how to scan for it - well, good luck there, it could be anywhere, and it could be nowhere. You'd literally have to scan every single URL on a site to find a problem - and even then you might still miss it.