Wednesday, September 24, 2014

Bash 'shellshock' bug is wormable

Early results from my scan: there's about 3000 systems vulnerable just on port 80, just on the root "/" URL, without Host field. That doesn't sound like a lot, but that's not where the bug lives. Update: oops, my scan broke early in the process and stopped capturing the responses -- it's probably a lot more responses that than.

Firstly, only about 1 in 50 webservers respond correctly without the proper Host field. Scanning with the correct domain names would lead to a lot more results -- about 50 times more.

Secondly, it's things like CGI scripts that are vulnerable, deep within a website (like CPanel's /cgi-sys/defaultwebpage.cgi). Getting just the root page is the thing least likely to be vulnerable. Spidering the site, and testing well-known CGI scripts (like the CPanel one) would give a lot more results, at least 10x.

Thirdly, it's embedded webserves on odd ports that are the real danger. Scanning for more ports would give a couple times more results.

Fourthly, it's not just web, but other services that are vulnerable, such as the DHCP service reported in the initial advisory.

Consequently, even though my light scan found only 3000 results, this thing is clearly wormable, and can easily worm past firewalls and infect lots of systems. One key question is whether Mac OS X and iPhone DHCP service is vulnerable -- once the worm gets behind a firewall and runs a hostile DHCP server, that would "game over" for large networks.



Update: As many people point out, the path variable isn't set, so I need '/usr/ping' instead to get even more results.

Update: Someone is using masscan to deliver malware. They'll likely have compromised most of the system I've found by tomorrow morning. If they using different URLs and fix the Host field, they'll get tons more.




26 comments:

  1. Well having to come across a CGI script written in Bash which is not the most popular language for CGI scripts is difficult. And on top of that you're looking only for this type of script running on the webroot so yeah, the massive scan may be missing a lot. Did you successfully test CPanel's /cgi-sys/defaultwebpage.cgi? I'd be surprised if it was Bash.

    ReplyDelete
  2. The question isn't whether a CGI is written in bash, but if it calls out to bash no matter how indirectly. Lots of things use the system() libc function, so if /bin/sh is bash it's game over.

    ReplyDelete
  3. True. That increases the chances of exploitation by probably a large factor.

    ReplyDelete
  4. Anonymous11:10 PM

    Depending on the OS the ping might be in different locations, e.g. /bin/ping, /usr/bin/ping, /sbin/ping, etc. You can use '/usr/bin/env ping'

    ReplyDelete
  5. is it useful to have a large set of links that end in .cgi?

    ReplyDelete
  6. I put together a vulnerability checker, but depends on wget or curl being available.

    Embeds wget and curl calls into the User-Agent, Cookie, and Referer headers, and if the test tool hears back from the called server, the vulnerability is confirmed.

    http://shellshock.brandonpotter.com

    ReplyDelete
  7. You just hit my server. It should have responded correct since its patched. Can we verify this?

    ReplyDelete
  8. Who would have thought that the system shell should be a simple, well-written piece of software?

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Just pondering but I suspect the oft-used Apache mod_status stats page is likely to use the shell(?): http://httpd.apache.org/docs/2.2/mod/mod_status.html

    ReplyDelete
  11. Our internal testing showed that /cgi-sys/defaultwebpage.cgi was not vulnerable by this exploit. It is not written in bash and does not make any calls to bash.

    If you have evidence to the contrary, or are aware of any other CGI scripts distributed by cPanel that are vulnerable we would greatly appreciate it if you'd open a ticket with us with this information:

    http://tickets.cpanel.net

    Thanks!

    Phil Stark
    Technical Support Supervisor
    cPanel, Inc.

    ReplyDelete
  12. How to fix create new none privileged user hide user disallow login change httpd id mapping to this new user the file should be in /etc change bash rc to set a new path, home etc... deny read and write to bin sbin etc... For the new user id then Create symbolic links of essential commands and files to what you pointed path to deny write for bash rc and any dir and folder that httpd does not need to know about

    Presto change you just correctly configured a web server

    Think security think need to know only give your users access to the things they need and never associate a none system daemon with root

    Look at the mobile account for an iPhone for inspiration

    ReplyDelete
  13. Surely this bug is dependent on apache/bash server running as root?

    I tried this on my own system at home and I cannot see how you can gain privilege elevation if you are running apache or bash as a non-root user.

    am I missing something

    ReplyDelete
  14. FluffSz you can still get output of /etc/passwd or other "relatively" sensitive stuff

    you can probably have fun with whoami, passwd, "rm -rf ~"

    ReplyDelete
  15. Can't you just set the default shell to csh for root and the webserver and call it a day?

    ReplyDelete
  16. The php run time library is not vulnerable (per CERT) - only the CGI implementation (which is very old and why would you still be using it?)

    With CGI, apache does a process creation for each invocation of a script, passing to it the environment variables that one would find in $_SERVER, $_GET, $_PUT, $_Cookie. the php executable is then started with those variables set. It is important to understand it doesn't matter -what- the environment variable is named - it's just easier to pass it into php via something like the user agent string.

    Once php is running with the bad environment variable, if it invokes bash directly or indirectly, it's game over. The payload is executed.

    As one person points out, that bash command will execute only with the credentials of the web server which should be apache.apache unless you ignored the way to properly install apache and not allow it to run as root.

    The first legitimate attempt against my system was going to do a wget to retrieve a payload, place it in /tmp and execute it

    The next attempt was trying to insert a plain/text header to cause apache to return the text of the php script rather than executing it - the goal being (probably) to find a hardcoded server name, userid and password to break into mySQL (if you're foolish enough to allow mySQL connections to anyone on the internet)

    ReplyDelete
  17. It would be interesting to see an "internet OS Count" type of survey, like the one at leb.net so many moons ago....

    http://leb.net/hzo/ioscount/

    ReplyDelete
  18. Anonymous5:03 PM

    Try this:

    $ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

    You will see one of 2 result:

    1) You are VULNERABLE IF YOU SEE THIS RESULT
    vulnerable
    bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
    bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
    bash: error importing function definition for `BASH_FUNC_x'
    test

    2) You are NOT VULNERABLE IF YOU SEE THIS RESULT
    bash: warning: x: ignoring function definition attempt
    bash: error importing function definition for `BASH_FUNC_x'
    test

    ReplyDelete
  19. If i run
    $ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
    script, my linux server behave abnormal things or it will be in normal position.

    ReplyDelete
  20. @hodha if you run the script as a normal user, nothing will happen except the text output

    (of course, don't trust me with this, google a few other descriptions)

    ReplyDelete
  21. @wheeler the scripts could use #!/bin/bash explicitly

    ReplyDelete
  22. Shellshock base bug is really dangerous issue. Now i fixed the issues on my server. use this method and fix the issue.http://www.freelancer.support/how-to-fix-shellshock-bash-vulnerability-in-ubuntu-under-open-vz/

    ReplyDelete
  23. How many sites did you scan? A flat number isn't a very useful statistic. You say "only 3k" so I'm assuming you scanned tens or hundreds of thousands of servers. The percentage is what interests me personally.

    ReplyDelete
  24. Anonymous10:04 PM

    As time goes by it is slowly but surely becoming apparent that too many yellow journalists/ bloggers and security companies dying for publicity have in effect been "Chicken Little" claiming the sky is falling.

    All these Bash shell one liner tests are idiotic. I can run 'rm -rf *' in my bash shell and destroy my computer - that doesn't prove its vulnerable. The fact is that a hacker would have to find an injection point. And those injection points already exist through bad web design which casts no shadow on the OS AT ALL!

    When you delve into expert forums and really learn about this issue - its pretty much a "patch and move on" feeling. Far short of the Chicken Little scenarios posted by idiots reading other idiots inflamed posts.

    ReplyDelete
  25. Many government systems are still in CGI, including Indian railways, if servers are not patched quickly it can create havoc.

    J. Paul

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

    ReplyDelete

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