Internet security has reached the highest defcon level. Another day, another hack – the new bug on the scene known as “Shellshock” blew up headlines and Twitter feeds.

1. Was the Cloud ShellShocked?
Internet security has reached the highest defcon level. Another day, another hack – the
new bug on the scene known as “Shellshock” blew up headlines and Twitter feeds.
Shellshock exposes a vulnerability in Bourne Again Shell (Bash), the widely-used
shell for Unix-based operating systems such as Linux and OS X. The bug allows the
perpetrator to remotely execute commands on vulnerable ports. The vulnerability is
extremely easy to exploit, not requiring extensive knowledge of application or
computational resources. The extensive functionality, along with the relative ease of
launching an attack, led industry analysts to label the bug more serious than
Heartbleed. The National Institute of Standards and Technology assigned the
vulnerability their highest risk score of 10.
What are the implications of ShellShock for Cloud Security? At Skyhigh, we
reviewed enterprise use of over 7,000 cloud service providers for vulnerabilities. The
results surprised us.
We initially expected to discover rampant vulnerability to Shellshock amongst cloud
service providers. The data portrayed a more mixed-bag of cloud application security.
4% of end-user devices in the enterprise environment employ the vulnerable version
of Bash on employee devices – reflecting the dominance of Windows in enterprise
networks. We also found that only three cloud service providers employ common
gateway interface (CGI), the primary vector of attack. While cloud service providers
may be vulnerable through other vectors (i.e. ForceCommand), the fact that they
avoid the primary attack vector of the bug through design and architectural
complexity is an indication of the maturity of today’s cloud applications.
However, when we scanned the top IaaS providers(e.g. AWS, Rackspace) for the Bash
vulnerability, 90% of checks reported the vulnerable Bash version on the default
images provisioned. Customers should not wait and rely on their IaaS providers to
take the initiative. To ensure immunity from ShellShock, all organizations should

2. immediately update their systems with the latest version of Bash.
But remediation measures shouldn’t end there. Given the current rate of breaches,
organizations can expect the next event won’t be far off. Our recommendation: A Web
Application Firewall (WAF) deployed to protect against pre-defined attack vectors
can come in handy at times like this. System administrators can quickly write rules for
WAFs to defend against this and similar bugs. In our case, we quickly updated our
WAF rules in addition to updating the vulnerable Bash version.
A Sample ruleset for mod_security (WAF) is as below:
Request Header values:
SecRule REQUEST_HEADERS “^() {”
“phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:’CVE-2014-6271 – Bash
Attack’”
SERVER_PROTOCOL values:
SecRule REQUEST_LINE “() {”
“phase:1,deny,id:1000001,status:400,log,msg:’CVE-2014-6271 – Bash Attack’”
GET/POST names:
SecRule ARGS_NAMES “^() {”
“phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014
-6271 – Bash Attack’”
GET/POST values:
SecRule ARGS “^() {”
“phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014
-6271 – Bash Attack’”

3. File names for uploads:
SecRule FILES_NAMES “^() {”
“phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014
-6271 – Bash Attack’”
Author :
Lauren Ellis is a research analyst covering the technology industry’s top trends &
topics, focusing on Cloud Security, Cloud Computing, Data Loss Prevention etc.,