About CVE-2014-6271

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. Today, CVE-2014-6271 was made public after its discovery last week by Stephane Chazelas. This vulnerability inallows an adversary who can pass commands toto execute arbitrary code. Asis 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

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.