[jrochkind1]

The exploit is worse.

But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing.

Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge.

But as it is... I'm not sure?

[Erwin]

You could search for *.cgi scripts indexed by Google. They may not be written IN Bash but maybe one of them opens up a shell to execute a command. Even if you are not explicitly passing any bad data to it, the environment will be passed and trigger this crazy vulnerability.

[ilconsigliere]

Makes sense. This just strikes me as a very flexible exploit.

[jrochkind1]

okay, i was wrong, this is way way worse.

[apawloski]

Google inurl:cgi-bin inurl:.sh

[jrochkind1]

Yeah, that makes sense. Did you try it?

Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't).

I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url.

inurl:cgi-bin inurl:".sh"

0 hits

[nisa]

    inurl:cgi-bin "inurl:\.sh$"

320k results here. The slash and $ made a difference but they are not parsed as regex other chars work too. Not sure what's going on here.