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."
... how many Linux servers are there?
It little behooves the best of us to comment on the rest of us.
From TFA:
The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses.
Bold is mine.
It little behooves the best of us to comment on the rest of us.
The screenshot in that article shows the shell prompt as "root@debian". But in reality, most Debian systems use "/bin/dash" as the default system shell instead of /bin/bash, which means most Debian systems are extremely hard to compromise; a CGI or system() call would have to go out of its way to invoke bash instead of dash.
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.
I don't know bullshit from wild honey about Linux, but the attack on the DoD is looking for Telnet.
Analysing the malware sample in a sandbox, we saw that the malware has conducted a massive scan on the United States Department of Defence Internet Protocol address range on port 23 TCP or Telnet for brute force attack purposes," ...
It little behooves the best of us to comment on the rest of us.
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.
How does one automate such a scan?
Right now, I think they're just blindly hitting web servers with headers set to exploit the vulnerability and hoping they get lucky. So less of a "scan" and more of a "spray and pray" type deal.
I think some versions of Apache shipped with a cgi-bin that contained a shell script as an example, so that would be another thing to try hitting first.
You are in a maze of twisty little relative jumps, all alike.
I guess you cocksucking faggots should have used Microsoft Windows Server instead of something as insecure as Linux.
For best results use Microsoft Windows, faggots!
Well, ask Home Depot and Target their opinions. I am sure they are right there with you.
To clarify:
Each /8 block contains 16,777,216 addresses.
It little behooves the best of us to comment on the rest of us.
"she'll commands"? A little submissive, are we?
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
You're a developer so you should know more ;) I mostly use zsh myself, but I'm curious as to what benefit or convenience feature this behavior gives to bash? Also are "normal" uses vulnerable or just web servers?
... how the indignation at a major vulnerability like this (2nd in a few months) is so muted when the OS in question doesn't come from Microsoft.
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.
At least one of them in charge of each group of systems should be that or an equivalent. Being good at Skyrim is not enough to effectively run systems over time.
It depends largely on weak web-facing CGI pages that don't sanitise inputs before passing them as arguments to a shell script.
So this is the bash rough equivalent to an SQL Injection Exploit?
I saw scans today starting just after noon Pacific Time.
It was just lazy programming. it's not an intentional feature. I doubt it's a useful feature either.
Time to put on some pants, UNIX/Linux geeks: ain't no operating system out there immune to error.
No fucking kidding, software has bugs. And this is a doozy. It's not the first WTF moment we've seen, and it probably won't be the last.
As with the Y2K problem, though, the proof of the pudding is in the tasting. The real test will come when we look back and measure the impact. Will we see a digital wasteland, a web devastated by shellshock-ing predators? Will we find ourselves living in an online New Jersey of the soul, wretched, empty bit-badlands stretching out to the horizon in every direction? Will the Evil Bit finally be flipped? Or will this be like the day when the public library almost burnt down, but we saved all the books by forming a bucket brigade? It's too early to say, right now. But my guess is that, unlike Microsoft's legacy, the fall-out from this event will be the stuff of a cautionary tale for young systems developers, explaining how all the cleverness in the world won't save you from stupidity, so the only really good system is one that can be patched quickly, effectively and simply.
Kant might also have admitted that, while no straight thing was ever made, quite a few bent things were subsequently straightened.
Crumb's Corollary: Never bring a knife to a bun fight.
I just updated Ubuntu 14.04. The first vulnerability which was CVE-2014-6271 would show up with the following line in bash: :;}; echo vulnerable' bash -c "echo this is a test" ... if it says 'vulnerable', then you are, and if it says 'this is a test' you are safe (from CVE-2014-6271). ...but there was a second attack vector, and US Cert gave it a second number CVE-2014-7169. ... and if it gives the date, you are still vulnerable. And I was until I got a second update from Ubuntu just a few minutes ago (although it could be older than that). And when you are safe from CVE-2014-7169 the second script returns: .... and that seems to be it. I haven't tried to run my massive software build (about 15 interconnected bash scripts that compiles a software stack consisting of about 30 pieces of software), but I will likely do it tomorrow. In on instance did I ever try to put executable code into environment variables (I didn't know you could), so I don't think I will be affected.
env x='() {
the second attack vector can be shown in a compromised version of bash with the following line:
env -i x='() { (a)=>\' bash -c 'echo date'; cat echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
date
cat: echo: No such file or directory
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?
At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...
Well...
As a software engineer they expect me to be a sysadmin.
I know that feeling all too well...
Just the other day I commented in a SystemD discussion how scripts break easily and are slow to execute. One of the replies I got was "Scripts don't break themselves. They do exactly what you tell them to do." Heh, indeed they do. Didn't we just hear about one Shellshock-related attack where a malicious DHCP server can command a dhclient script do nasty things. Scripting is a problem and binary modules would provide more robust interfaces. It is a thing worth giving a thought.
It's an exceptionally commonly used feature to have functions pass through to sub-shells that get invoked in a script whether due to explicit sub-shell syntax with parentheses or implicitly in pipelines or other control blocks with I/O redirection on them.
What's broken is that the functions are passed through in such a grotesquely unsafe way via the same environment namespace that regular applications would use, rather than setting up an appropriate IPC mechanism between the parent and sub-shell.
I do not understand the problem
“He’s not deformed, he’s just drunk!”
I'm not sure this is too big a deal. You hear about the problem and you patch it. Both the systems I have that are Internet facing use distros that had new bashes available very quickly. Yesterday morning I wasted 15 minutes on this. We'll now be reading about it for the next month.
I guess the problem will remain for those that don't patch.
Ignoring the pointlessly offensive comment about Skyrim, I think requiring a software engineer as part of every IT infrastructure team maintaining Linux servers seems difficult to achieve. I'm not saying it's extremely rare, but I don't think it's all that frequent right now, at least not outside of Fortune 500 companies or so. Furthermore, even if you had one in your team, what makes you think he will be able make a patch for bash faster than to wait for one to be released?
We knew 15 years ago, that using shell-scripts as CGI-scripts was a security problem.There's just so many ways for a not perfectly quoted variable to become a script injection.
And for those who system() - if you are doing that without validating user input - and those header environment variables ARE user input - you just failed security 101.
So, can anyone explain to me how to use this bug, without using an existing vulnerability to get to it?
I see two groups of people, one group exclaiming that this is a serious vulnerability, without being able to explain how it's a vulnerability, and the other (including myself) saying that it's not a vulnerability, because you need to already have a vulnerability to get to it.
Are you joking or trying to mislead?
I really mean being able to build from source including patches faster than a package comes out for the platform, which may be weeks or never if the platform is an old software distribution. That's the bar I'm setting for "software engineer". It may be a bit lower than what you mean.
its not just shell cgi scripts , other services pass data they receive through environment variables , these include dhcp clients and any other non authenticated services.
a simple fix is to use a different shell for now.
[site]
Has it been going on.
"If any question why we died, Tell them because our fathers lied."
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.
I'm still waiting for an example of how to get to this so-called vulnerability, without using a different security hole to get to it. Either some moron letting the web server call bash directly, or someone not sanitizing his inputs.
I disagree that using shell CGI scripts should be considered security hole any more than using CGI scripts written in any other language, but if you want other examples of exploiting this bug you can do it via malicious DHCP responses processed by dhcpclient or by env. variables passed when loging in via SSH.
If the systems really had the /bin/bash exposed, then they were insecure from the day one. It is just that nobody had realized that before.
Otherwise I wonder whether the Debian's /bin/sh being the dash somehow mitigated the problem for the Debian system?
All hope abandon ye who enter here.
At the bottom of the page, click on the "Classic" link.
New instance, new OS, new browser - but it really took 2 minutes to find how to deactivate the bucking feta.
All hope abandon ye who enter here.
Yes, I think we had totally different things in mind when you mentioned the term "software engineer", especially now that you reduce the term to being able to apply a patch to source code.
So... unless your CGI script is extracting a header field and feeding it to a bash script... you should be okay in terms of HTTP requests with this in their header?
Keep your head in the sand, it's less scary that way.
Or realise that your CGI server feeds headers to your CGI processes in environment variables, because that is how CGI is supposed to work, and that it isn't just your CGI script it is every single process it starts (all children and descendants) that must not be a shell script and must not use system() etc. Perhaps then also note that CGI is just one vector that happens to be being attacked right now and there will be others, some we probably don't know about yet.
Or you could assume you are vulnerable and patch bash, or remove it.
Your web server might be responding with a 200 response code, but that's just because whatever the URL requested is, is being successfully sent.
Thoughts?
Correct - no need for attacks to cause any error at all. May be possible using an http header you aren't logging at all, giving you no way to detect it.
However, this has nothing to do with users on your box maybe trying to do privilege escalation with this bash trick. But... this isn't a privilege escalation trick - the user shouldn't have any more access to the system than he would have with running the commands directly, right?
Find a setuid script or setuid program that somewhere uses the shell and it's a privilege escalation too. Such things _should_ be very rare by now, but not impossible that some still exist.
It does not automatically mean that, but money can buy you some nice quality assurance and code auditing.
Can it? Could you point out an example of that?
(Outside, possibly, the Space Shuttle landing software).
I think the bigger than heartbleed comments might be a bit overblown. If you're running CGI and your web server is running as root, you probably have a serious problem. Otherwise, it's just a PITA when you have other things to work on. Can anyone tell me why the script kiddies are scanning 23? I haven't seen an open telnet port in years. From all the reports I've read, about the only things vulnerable are web servers running CGI which was pretty vulnerable before.
ssh is also vulnerable (often configured to pass TERM and maybe LC_*)
Git repos using locked-down ssh - vulnerable
dhclient - vulnerable
CUPS - vulnerable
Those are just the ones we know so far.
It is different to heartbleed, and it could indeed get bigger. Heartbleed required zero effort to get the data but then needed some luck and some work to find keys or login info within it. Manual work required before you could break into a system.
ShellShocked on the other hand is direct, trivial, remote code execution. Attacks can easily be fully automated - it is wormable, trivially. The question now is not whether or not fully automated worm attacks will happen or when - they already are - it is how many servers they will get.
And that is all before we start looking at all the embedded Linux out there that may have bash, and often have cgi. It may take longer to find exploit vectors for those, but it will also take longer to patch, and some may not be patchable. Add in to the mix that small business / home routers often also run dhcp servers, and that dhclient is vulnerable, and a router compromise can open up any unpatched client machines inside the firewall.
No one knows how big this _will_ get, but it _could_ be bigger then HeartBleed, easily.
I see two groups of people, one group exclaiming that this is a serious vulnerability, without being able to explain how it's a vulnerability, and the other (including myself) saying that it's not a vulnerability, because you need to already have a vulnerability to get to it.
I'm with you. I've been trying to figure out what the exact attack vectors are here. The only thing I'm realistically worried about is what pieces of shit PHP code are out there running galleries, forums, blogs, etc, that call out to shell... I'm thinking a creative USER_AGENT string may be a good way to get unfiltered user data into $SHELL... I think in the short term, I'm not worried about dhclient-script because I don't have a linux laptop but if I did, I don't find myself attaching to random wifi hotspots, and if I did, it'd be at a pub which is unlikely to, in the short term, find themselves compromised...
Does php even use a CGI connector these days?
I must not be a good sekurity eckspert because I'm not seeing the world-ending exploit here.
I'm not sure why you felt the need to blame the victim on this, but the reality is that this is a problem not because of lax security measures on the part of server maintainers, but because it allows attackers to bypass good security measures if the shell being used is Bash.
And, because the exploit makes services such as SSH vulnerable, it can be used even if normal modes of passing data to the server are sanitized.
while(1) attack(People.Sandy);
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.
Or you could assume you are vulnerable and patch bash, or remove it.
Patch bash with what, exactly? Patch #25 didn't fix the problem completely and there's nothing newer than Patch #25 at gnu.org:
ftp://ftp.gnu.org/gnu/bash/bas...
Case in point, perhaps...
Mediawiki has:
$wgDiff3 = "/usr/bin/diff3";
Maybe nobody uses Mediawiki anymore...
"I'm still waiting for an example"
So, instead of doing what everyone else did and look up what was vulnerable and how shell shock could be exploited in SSH (which NIST specifically mentions), you chose to make up a bullshit idea about how it could be exploited that conveniently fit your "holier than thou" attitude about security and argue from ignorance about the exploit.
Good call.
while(1) attack(People.Sandy);
I know for a fact that my home router shells out to IP Chains to generate the NATed ports page. It will show this page to anyone and I can't turn it off -- remote administration is OFF, but for my router that just means only 192.* addresses can login and change things like the NATed ports. It still serves up the web pages to all requestors.
I disagree that using shell CGI scripts should be considered security hole any more than using CGI scripts written in any other language (snip)
Shells are notoriously difficult to use securely. So much so that for example suid is often not honoured on shell scripts. And that's because of the documented behaviour of the shells. The newly discovered bug in the Bourne shell makes it particularly easy to write an exploit, but even based on just the documented behaviour you're either a fool or a genius if you think you can write secure shell scripts.
It may be true that it is perfectly safe to cross the Niagara over a steel cable if you're trained well enough, but normal people are nevertheless advised to just use the bridge.
> Of course, as a sysadmin I should also be a software engineer. How stupid of me.
Yes you are stupid. Being enough of a "software engineer" to patch bash is a pretty pathetically low bar for any computing professional anywhere. It doesn't matter if they are "only a sysadmin".
It's not exactly rocket science.
This is what you get when your OS vendor tells you that you can have trained monkeys manage your systems.
A Pirate and a Puritan look the same on a balance sheet.
As a software engineer they expect me to be a sysadmin.
As a sysadmin, I'd say that's a crazy idea. However if you are capable of digging into such, it must mean that you're quite attractive an an employee, and in some ways makes you a better software engineer too.
Politics; n. : A religion whereby man is god.
No. The problem is that bash allows functions to be defined AND run in a variable declaration. It's the classic case of muddling the line between data and programs. This is what allows a remote exploiter to feed anything they like into your copy of bash.
Defining functions in environment variables seems like a weird idea. Is anyone crazy enough to use that and if so then why?
A Pirate and a Puritan look the same on a balance sheet.
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74 :; }; ping -c 3 209.126.230.74 :; }; ping -c 3 209.126.230.74
http-header = Host:() {
http-header = Referer:() {
The ping command makes the remote server ping that destination. Commanding the server to ping not respond to a ping. That is a none destructive test of an apache web site.
love the taste, hate the texture
It turns out that bash was JavaScript before JavaScript was cool.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
What about Mac OSX DHCP client?
Check your distro. Believe RedHat at least have newer allegedly more complete patches - although there are also posts saying you'll need a support contract for some older versions of RedHat.
My guess is that initially this was embargoed while GNU/FSF guys "fixed" it, but when we find out fact that the fix was no good everything is already public so now everyone downstream is trying to fix it themselves as fast as possible - RedHat etc. may do their own without waiting for upstream. It's now that you find out how good your support is, from whoever you paid for it or from the guys who work for free if you paid no one.
If you want the diy approach, personally I would look at the initial patch for where the offending code is and rip out the entire "feature", I suspect very few scripts will break.
Alternatively, patch bash using rm.
As an actual certified professional engineer that now happens to work in IT I'm constantly reminded that the term now applies to an intermediate technician skill level. Sorry I misunderstood that you seem to mean someone in more of a lead role.
Anyway, I was trying to push the point that at least one person who at least has some grasp of programming should be in each group of sysadmins or able to be called in by them at short notice. Otherwise the sysadmin just becomes the guy that can follow a Standard Operating Procedure and calls phone support if something is not on the list. Why did we spend so much time learning about stuff if we're not going to be capable enough to write a new S.O.P. when things change?
I've forbidden shell interactions from web servers forever on my client systems and I'm always in shock that online control panel systems allow direct shell access to the system. It just seems obviously wrong.
- Michael T. Babcock (Yes, I blog)
At no point are you not in control of the environment variables in question; unless you're allowing unsanitized input of course.
- Michael T. Babcock (Yes, I blog)