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 todays 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 shouldnt end there. Given the current rate of breaches, organizations can expect the next event wont 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
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 todays 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 shouldnt end there. Given the current rate of breaches, organizations can expect the next event wont 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
SHARE
