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:

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.

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:

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

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)

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/

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.

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.