Why the cloud wasn't 'Shellshocked' and how to prepare for the next vulnerability
Why the cloud wasn't 'Shellshocked' and how to prepare for the next vulnerability

The initial flurry of activity and media interest surrounding Shellshock has died down now but revisiting these events and vulnerabilities after the fact can be extremely valuable as a lesson-learning exercise or as a way of uncovering new trends. In the case of Shellshock, its impact on cloud computing certainly makes for interesting reading.

There has been plenty written about Shellshock already but here's a reminder of the basics. 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 perpetrators 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, even led the National Institute of Standards and Technology to assign the vulnerability their highest risk score of 10.

Upon discovery, Shellshock caused many security experts to suggest that the bug is more serious than Heartbleed, but if you study the data of SaaS providers carefully – and particularly enterprise-ready SaaS – you'll find that the vast majority of cloud computing applications were remarkably well prepared. Indeed, you could make a strong case to say that these online services were actually more secure than legacy apps, as none of the major SaaS vendors seem to have had any issue with Shellshock. This flies in the face of perceived notions regarding cloud security, and may challenge any organisations still sceptical about moving to SaaS solutions due to security issues.

Skyhigh Networks' data on the enterprise use of more than 7,000 cloud services showed that vulnerability to Shellshock was limited. A mere four percent of end-user devices in the enterprise environment employ the vulnerable version of Bash on employee devices – unsurprising perhaps given the dominance of Windows in enterprise networks. The numbers continue to get smaller too, of these 7,000+ cloud services, only three employed common gateway interface (CGI), the primary vector of attack. While cloud service providers may be vulnerable through other vectors (ie 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.

It's not all good news, however. When the top IaaS providers (eg AWS, Rackspace) were scanned for the Bash vulnerability, 90 percent of checks reported the vulnerable Bash version on the default images provisioned. It's important that customers do not wait and rely on their IaaS providers to take the initiative when these vulnerabilities are discovered. To ensure immunity from ShellShock, for instance, all organisations should immediately update their systems with the latest version of Bash.

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


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

Remediation measures shouldn't end there. Given the current rate of breaches, organisations can expect the next event won't be far off – POODLE only served to highlight this fact and you can bet there will be another vulnerability discovered soon. In terms of proactive measures that can and should be taken, a Web Application Firewall (WAF) deployed to protect against pre-defined attack vectors can come in handy at times like this.

We're moving into a new era of IT where online applications are starting to pull ahead of on premise when it comes to security features and sophistication. While there will always be a place for on premise apps, this is certainly an interesting development and one to keep an eye on when the next wave of software vulnerabilities make headline news. When this happens, the cloud and any organisations that have made it a priority to leverage cloud applications may be the least affected.  

Contributed by Pathik Patel, senior security engineer, Skyhigh Networks