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:

Unknown said...

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.

Unknown said...

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.

Unknown said...

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

Anonymous said...

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'

AKSHAY BHAT said...

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

Unknown said...

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

Unknown said...

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

sswam said...

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

Unknown said...
This comment has been removed by the author.
Unknown said...

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

Unknown said...

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.

Unknown said...

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

Unknown said...

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

ChrisK said...

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

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

wheeler said...

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

FindAnISP said...

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)

Justin Goldberg said...

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/

Anonymous said...

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

hodha said...

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.

Alexander said...

@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)

Alexander said...

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

Vijayakumar said...

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/

Unknown said...

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.

Anonymous said...

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.

javin paul said...

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

J. Paul

felisha green said...
This comment has been removed by a blog administrator.