Some stats from ShellShock test tool analysis

It’s been an interesting past few days. As you can probably tell from the counters at http://shellshock.brandonpotter.com, the vulnerability test tool logs some statistical information.

When the tool sends a HTTP request, it contains a special URL that, if successful, lets us know that the bash command was executed on the remote system, and via which type of HTTP header embed was successful in executing the command.

At the time of this post, a little over 121,000 tests have been run, representing approximately 88,000 unique hosts. The vast majority of systems have not been affected in a way that this tool detects. Last week, it was around 8% of systems, and as of today that number has dropped closer to 6% and continues to drop. Here is the breakdown of vulnerabilities that the tool has found:

  • 35% – Cookie Attack – These sites were susceptible to a bash command embedded in a Cookie HTTP header.
  • 33% – Referer Attack – Bash command embedded in a Referer HTTP header.
  • 32% – User-Agent Attack – Bash command embedded in a User-Agent header.

So, it’s roughly evenly distributed across HTTP headers, but Cookie is the most vulnerable by a few points.

The test tool also uses a few different commands, since it depends on wget or curl and these may be located in different locations. /usr/bin/wget is by far the most successful, with 52% of the vulnerabilities identified through it. (Not that this matters, since most intentional attacks would likely focus on doing something a little more evil than wget’ing a URL, but it has been interesting to see which worked.)

Note: Keep in mind that this is a HTTP test tool only, and while HTTP is the easiest and most open attack point to your servers, it is not necessarily the only way this can be exploited if you didn’t patch. For the test tool to find a vulnerability, you must have a vulnerable Bash shell, in addition to a CGI script / environment running on your web server that calls Bash to do something.

On a different, more mildly interesting note of how folks are testing their junk…

There is a disclaimer that the test tool should only be used on your own sites. Of the crazy people, the misfits, the rebels, the troublemakers:

  • 695 people have tested google.com – fear not, they have things under control over there now.
  • 259 people have tested facebook.com – uncle Mark would be proud.
  • 155 people have tested shellshock.brandonpotter.com (y’all think you’re funny)
  • 75 people have tested 127.0.0.1 (again this is why we can’t have nice things)

A few of the popular sites have been blocked now, since it’s just a waste of resources at this point testing them over and over. I’m no fun.

Looking through the web logs, honorable mention goes to the good people testing these “sites”…

  • -1 or 1=1 and (select 1 and row(1,1)>(select count(*),concat(CONCAT(CHAR(95),CHAR(33),CHAR(64),CHAR(52),CHAR(100),CHAR(105),CHAR(108),CHAR(101),CHAR(109),CHAR(109),CHAR(97)),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 1))
  • 1' || (select dbms_pipe.receive_message((chr(95)||chr(33)||chr(64)||chr(51)||chr(100)||chr(105)||chr(108)||chr(101)||chr(109)||chr(109)||chr(97)),25) from dual) || '
  • (select convert(int,CHAR(95)+CHAR(33)+CHAR(64)+CHAR(50)+CHAR(100)+CHAR(105)+CHAR(108)+CHAR(101)+CHAR(109)+CHAR(109)+CHAR(97)) FROM syscolumns)