Akamai Diversity

The Akamai Blog

Environment Bashing

[UPDATE: 9/25/2014 11:30AM]

Akamai is aware that the fix to CVE-2014-6271 did not completely address the critical vulnerability in the Bourne Again Shell (bash). This deficiency is documented in CVE-2014-7169. The new vulnerability presents an unusually complex threat landscape as it is an industry-wide risk.

Akamai systems and internal Akamai control systems have been or are being urgently patched or otherwise mitigated in prioritized order of criticality.

Akamai has developed an emergency patch for today's vulnerability which makes function forwarding conditional on the compile-time switch "FUNCTION_EXPORT". We're using it for systems that can't be switched to the Almquist Shell. In the hope that it's useful to others, and for public review, we've posted that patch at https://bit.ly/ShellShockPatch.



About CVE-2014-6271
Today, CVE-2014-6271 was made public after its discovery last week by Stephane Chazelas. This vulnerability in bash allows an adversary who can pass commands to bash to execute arbitrary code.  As bash is a common shell for evaluating and executing commands from other programs, this vulnerability may affect many applications that evaluate user input, and call other applications via a shell.  This is not an Akamai-specific issue; this impacts any system that uses a vulnerable bash.
Akamai has validated the existence of the vulnerability in bash, and confirmed its presence in bash for an extended period of time.   We have also verified that this vulnerability is exposed in ssh---but only to authenticated sessions. Web applications like cgi-scripts may be vulnerable based on a number of factors; including calling other applications through a shell, or evaluating sections of code through a shell.  
There are several functional mitigations for this vulnerability: upgrading to a new version of bash, replacing bash with an alternate shell, limiting access to vulnerable services, or filtering inputs to vulnerable services.  Akamai has created a WAF rule to filter this exploit; see "For Web Applications" below for details.
Customer Mitigations
Systems under our customers' control which might be impacted include not only vulnerable web applications, but also servers which expose bash in various ways.  System owners should apply an updated bash with a fix for this vulnerability as expeditiously as possible.  In the meantime, there are several workarounds that may assist.
For SSH servers:  Evaluate the users who have access to critical systems, removing non-administrative users until the systems are patched.
For Web Applications: CGI functionality which makes calls to a shell can be disabled entirely as a short term measure; alternately WAF mitigations can be deployed.  The following Akamai WAF protections will assist customers that have purchased the Kona Web Application Firewall or Kona Site Defender services:
  • All customers of Akamai's web acceleration services (Ion, Dynamic Site Acceleration, EdgeSuite, Object Delivery, and similar) are protected against some attacks using this vulnerability by Akamai's HTTP normalization.  Attack text in Host headers, HTTP version numbers, and similar will be silently discarded by the Akamai Platform.  
  • Use of the "Site Shield" feature can further enhance the HTTP normalization protection by removing attackers' ability to connect directly to a customer web server.
  • Customers who use the new Kona Rule Set are protected against some attacks using this vulnerability if they enable the Command Injection risk scoring group.  This scoring group is being extended today to provide more comprehensive coverage by incorporating specific rule triggers for this vulnerability.  
  • We also have a custom WAF rule which will provide a targeted defense against this specific vulnerability.  This WAF rule operates by filtering on the four-byte attack string '() {' in the request header or body . It can be implemented to cover both headers and query strings (for maximum safety), or headers only (in the event that query strings generate too many false positives).  The custom rule is available to customers by contacting their account team.  It will be available for self service today.
  • This custom WAF rule will shortly be available for self-service provisioning for non-KRS customers.
Akamai Mitigations
Public-facing Akamai systems and internal Akamai control systems have been or are being urgently patched or otherwise mitigated in prioritized order of criticality. 
For many of our critical systems, Akamai first switched away from using bash to another shell, to protect those systems.  We did not make a universal switch, as the alternate shell was not completely feature-compatible with bash (not all of our systems would continue to operate with this change).
For other systems which could tolerate the downtime, we disabled those systems pending receiving an updated bash. For Akamai web applications which couldn't take an alternate shell and couldn't be disabled, we blocked many Akamai-owned CGI scripts at the Akamai Edge, until we developed and deployed the WAF rules above.
Do you have any evidence of system compromises?
No.  And unfortunately, this isn't "No, we have evidence that there were no compromises;" rather, "we don't have evidence that spans the lifetime of this vulnerability."  We doubt many people do - and this leaves system owners in the uncomfortable position of not knowing what, if any, compromises might have happened. 


Andy, how exactly was this vulnerability published? Shouldn't such a hack be disclosed to security professionals with some leadtime?

This vulnerability was coordinated among several operating system distributions and security vendors, and the publicly disclosed via a well-known security mailing list. Unfortunately, there is no reasonable way to conduct large-scale coordinated disclosure; and in that case, it might have proved harmful, as several additional vulnerabilities were found that wouldn't have been fixed in an initial wave of patching.