[yeahforbes]

I'm doing the same, and wondering to myself if that string is actually comprehensive. Are there variants, and if so can they be included as log search patterns without tons of false positives?

I've got lots of wget commands in there like guylhem noted, attempting to either drop a script (and clean up) or phone home to normal random websites that were unfortunately compromised. The phone home requests have all sorts of URIs containing things from my hostnames to unique IDs.

[Gygash]

`:;' is not the best string to use to identify shellshock exploit attempts, as the contents of the function are ignored and can change.

Searching for `() {' _should_ (and I'm happy to be corrected here) find most attempts at exploiting, since that's the key sequence that triggers bash's "parse this environment variable as a function" behaviour.

[meowface]

Upon researching this, "() {" will always catch this.

If you look at the bash source code, the relevant parsing function checks if an environment variable begins with the literal 4-character string of "() {". That's why it's pretty easy to detect exploits: you can't do anything to evade a filter checking for this in an HTTP header. An HTTP server should not be doing any decoding of an HTTP header that could result in "() {" being obfuscated. This may not apply for attacks against things that aren't web apps, though.

[nitrogen]

Upon researching this, "() {" will always catch this.

Unless the input is decoded in some way before reaching an environment variable. E.g. HTML entities, hex escapes (percent or backslash), gzip, ... Best just to patch bash and switch to a different /bin/sh.

[meowface]

I should have said "will always catch this for CGI servers and HTTP headers".

[brians]

Some web servers helpfully remove some sorts of white space, like newlines. '() \n{' will get past many filters, then hit some CGIs behind such servers.

I would worry similarly about some mail headers being helpfully reassembled, then handed to procmail in environment variables.