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."
Italian? wopbot?
I'm at a loss for words - other than that seems offensive, even for non-politically-correct me.
"National Security is the chief cause of national insecurity." - Celine's First Law
no venerability should be without a logo :
https://twitter.com/johnjonesname
priceless excerpt: |The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses."
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.
I'm confused about how you can scan for vulnerable systems.
You and everyone else.
The attack surface is "anywhere you can influence the values of environment variables prior to bash being run." Where exactly is that? Well...
The easiest example of that are CGI scripts, where the web server will set environment variables to values that are taken directly from HTTP headers. If the CGI script is a bash script (why would you do that?) or ever happens to fork out to a bash script in any way (that's more understandable), it's vulnerable.
But that's just one example. Any place a remote value gets stuck straight into an environment variable and a bash script gets run is vulnerable. And people are almost certainly going to slowly find more and more places where that's the case.
If you just want to know if you're vulnerable, there are one-liners that will determine if you're still vulnerable, but since the first fix didn't, chances are, you very well could be.
You are in a maze of twisty little relative jumps, all alike.
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.
Well...
As a software engineer they expect me to be a sysadmin.
Seriously!
Shell scripts have been known to be basically insecure for a long time. Why would you expose one to a web or network interface?
Of course, that just leaves ssh, but at least some authentication SHOULD be required there.
It's that simple. Even with the patches, bash is still running the contents of environment variables through its general command parser in order to parse the procedure. That's ridiculously dangerous... the command parser was never designed to be secure in that fashion. The parsing of env variables through the command parser to pass sh procedures OR FOR ANY OTHER REASON should be removed from bash outright. Period. End of story. Light a fire under the authors someone. It was stupid to use env variables for exec-crossing parameters in the first place. No other shell does it that I know of.
This is a major attack vector against linux. BSD systems tend to use bash only as an add-on, but even BSD systems could wind up being vulnerable due to third party internet-facing utilities / packages which hard-code the use of bash.
-Matt
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.
If shellshock lets remote users execute arbitrary shell commands, should we just run a scan of the whole internet (https://github.com/robertdavidgraham/masscan), and issue apt-get update & apt-get upgrade? Use the bug to patch the bug?
1. the first fixes, within 24 hours of announcement, didn't actually fix it fully - in fact I suspect it will still be exploitable in some way or other until the "feature" of treating environment variables as code is removed completely
2. providing an incomplete fix may be worse than taking a bit longer to properly QA the fix - a lot of admins may believe they have patched this based on the first announced vulnerability tests and the first set of patches, but in fact they are still vulnerable with a trivial change in the malicious bash code
3. it was less than 24 hours after first being made public - this may be entirely unrelated to when it was first found
We have no idea who found it first or for how long it may have been used covertly (did NSA etc. know of heartbleed before public knowledge ?)
We don't know what prompted someone to be looking for problems in code that hasn't changed for 20+ yrs.
It is so trivial to get remote code run with this bug (no unexpected new process or login or errors) that I doubt it will trip any intrusion detection systems.
If you can use an http header that isn't logged, then you could run code on the server and extract information and it may be completely undetectable.
Something else we don't know is how the FBI really got the Silk Road server to cough its real IP address. The FBI claim they put "miscellaneous characters" into the login form and it just happened to send the address back. You can believe that if you want. It may or may not be related (I have no idea about the silk road server setup), but a handful of days after the FBI put their story out someone is looking for security holes / bugs in very old bash code. Maybe there was no trigger and they just happened to get bored one day and decide that looking for bugs in bash would be fun. Or maybe there is more behind this than we know.
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.