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
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!
and there goes the years of posturing by *nix fanboi's about how secure *nix is and how Insecure Micro$oft is.
A self-propagating infection like the SQL Slammer.
Software is software and while-ever soft quishy things (ie: people) write it vulnerabilities will exist.. even if not found yet.
no venerability should be without a logo :
https://twitter.com/johnjonesname
You get what you pay for, I guess. Thanks again for making the internet less secure, freetards!
just read the code and code the patch yourself, easy
priceless excerpt: |The US DoD network in question is the 215.0.0.0/8 range, with approximately 16.7 addresses."
Christ, this could turn into armageddon. All these morons were duped into thinking they could get rock solid computer systems for free? WHERE DO I SIGN UP! What could possibly go wrong? Using stuff that people whip up at home for no money is a much better idea than using secure systems that experts were paid to design and code correctly. And then I'll load it up with the company and countries and customers most important information. Never. Fucking. Again. Will. I. Trust. Linux. Or any software that I didn't pay for, to store sensitive data. I hope someone starts filing lawsuits against the companies that get hacked for not properly securing their customer's data.
... 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.
It seems that you need to have the ability to execute an arbitrary bash command to actually make use of this weakness. So does that mean that in order to run it in a remote machine, you need to already have access to that machine? I'm confused about how you can scan for vulnerable systems.
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.
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.
To clarify:
Each /8 block contains 16,777,216 addresses.
It little behooves the best of us to comment on the rest of us.
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
You can check if you've been scanned for exploitable CGIs using something like (adjust apache logs path accordingly):
grep cgi /var/log/apache2/access*|egrep "};|}\s*;"
Thanks for the nice grep work - found one attempt to get my box to rat itself out via ping:
/var/log/apache2/access.log:89.207.135.125 - - [25/Sep/2014:03:52:14 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1799 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
Fortunately I was patched several hours prior to that.
Would there be any way for that probe to execute against a static 404 page - no cgi executing?
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.
Only 51 comments as of this post? Sort of like way back when Sun Microsystems tried to trademark "enterprise". Crickets. One can only imagine the trollbait / flamestorm that would break out if Shellshock were a Microsoft bug. Time to put on some pants, UNIX/Linux geeks: ain't no operating system out there immune to error. Or, as Immanuel Kant once wrote: "Out of the crooked timber of humanity, no straight thing was ever made."
I saw scans today starting just after noon Pacific Time.
The web server I checked had the same attack done on it...with the same source IP...and even the same ping address!
Just update Bash, jeeez
It was just lazy programming. it's not an intentional feature. I doubt it's a useful feature either.
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?
The prober is sending this string in an HTTP header field (I've received these from 3 different IPs over the past couple of days - I've seen these in the web server logs):
"() { :; }; /usr/ping -c 3 [some ipv4 address to ping]" :; }; ping -c 11 [some ipv4 address to ping]" :; }; /bin/ping -c 1 [some ipv4 address to ping]"
"() {
"() {
I'm seeing these in the "Referer" header and "User Agent" header. There are other http header fields: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields. I'm not logging those headers, only the defaults I mentioned just now.
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?
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?
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?
At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...
Hackers took over my Gentoo box you insensitive clod!
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.
Here is your daily buck feta broadcast. So, buck feta.
Buck Feta. You know what to do.
I do not understand the problem
“He’s not deformed, he’s just drunk!”
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.
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.
A self-propagating infection like the SQL Slammer.
It's funny how (a) you don't have a fucking idea what you are talking about and (b) you get your paradigm for exploits from your own system ignoring completely how other systems work. That's fucking hilarious! HAHAHAHAHHAHAHAH
Are you joking or trying to mislead?
... 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.
Bugs happen. The bullshit and coverup that comes with many of them needn't happen.
When did shellshock come out? A week ago?
We already have testing routines, fixes, live reports on ongoing exploits, ad-hoc sidetracking fixes for commercial non-FOSS versions (Mac OS X), countless how-tos on how to close up holes, a lively worldwide debate among experts on how to prevent this class of exploit, the bash crew merging the fixes, existing updates for debian, etc.
Seriously, this is a *very* *bad* hole, and yet the cool with which I was able to approach it simply knowing that all my outward facing boxes run a type-a prime FOSS distribution like debian was something you will not see with a windows admin. apt-get upgrade, apt-get update ... bladibla blubdiblub packageA bash someOtherPackage ... bladibla continue? Fuck yeah. Hit Enter. Yawn. Go get some coffee, come back, paste the onliner test. Fixed.
Sorry pal, but even with a bug of this magnitude, the way the FOSS community deals with it is a whole different league than any other camp. Openness beats everything else in this line of work, every time.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
there was a huge bot net some time back on windows that tried to eat TOR, it got zero press, years before google "Nimda" if any real info is left about it, you would be able to read how Microsoft hid behind linux servers to protect themselves.
shall I post the IP of my Debian box, so you can show me what you can do to it?
Has it been going on.
"If any question why we died, Tell them because our fathers lied."
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.
This will redirect them:
RedirectMatch permanent /cgi-sys/defaultwebpage.cgi https://www.youtube.com/watch?v=dQw4w9WgXcQ
echo Look Out For this semicolon separating commands; rm -rf
* If that sucker's being run with admin/root/superuser priveleges? Well, you know...
APK
P.S.=> Now that it's been patched, you *REALLY* have to wonder how many "bad guys" KNEW about it, long before this all came out, & what they DID with it - my guess is, they planted ALL SORTS of "bushwhacks" all over the place on *NIX variants, worldwide (worse than you're seeing now)... apk
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.
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."
For those entrenched in legacy platforms and technology - yep, they deserve it. might as well say AT&T UNIX System V is vulnerable if big iron heads are using it. 20 years ago, not so much in a closed network work, with just a DARPA kind of collective between institutes and government. Today, all bets are off; every home has a super command and control set of systems with high bandwidth capabilities to attack and sever critical systems across the world.
We deserve what our inept IT leaders don't want to admit. They deserve what they swallow - puke.
be well and may the force be with you.