Was the Cloud ShellShocked?

By Pathik Patel, Senior Security Engineer, Skyhigh Networks

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.

Four percent 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 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’”

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’”

We recommend evaluating this ruleset based on your own application design. For additional best practices, check out our five keys for protecting data in the cloud.