The Shellshock vulnerability, originally announced as one critical issue in bash that allowed an adversary to execute arbitrary code, has grown from one vulnerability to six in the last week. For background on Shellshock, we’ve collected an overview and list of the vulnerabilities
; for some history on Akamai’s initial responses, read our original blog post
Shellshock raised a lot of questions among our customers, peers, auditors, and prospects. This post addresses some of the most frequently asked questions, and provides an update on how Akamai is handling its operations during this industry-wide event.
Are Akamai production servers vulnerable? What is the status of Akamai mitigation?
Akamai’s HTTP and HTTPS edge servers never exposed any vulnerability to any of the six currently available CVEs, including the original ShellShock vulnerability. Our SSH services (including NetStorage) were vulnerable post-authentication, but we quickly converted those to use alternate shells. Akamai did not use bash in processing end-user requests on almost any service. We did use bash in other applications that support our operations and customers, such as our report generation tools. We switched shells immediately on all applications that had operated via bash and are deploying a new version of bash that disables function exporting.
Akamai’s Director of Adversarial Resilience, Eric Kobrin, released a patch for bash that disables the Shellshock-vulnerable export_function field. His code has aggregated additional upstream patches as available, meaning that if you enable function import using his code, the same behaviors and protections available from the HEAD of the bash git tree are also available. His patch is available
for public review, use, and critique.
We do not believe at this time that there is any customer or end user exposure on Akamai systems as a result of Shellshock.
What about Akamai’s internal and non-production systems?
Akamai has a prioritized list of critical systems, integrated across production, testing, staging, and enterprise environments. Every identified critical system has had one or more of the following steps applied:
- Verify that it the system/application is not using bash (if so, we disabled the vulnerable feature in bash or switched shells);
- Test that the disabled feature/new shell operates seamlessly with the application (if not, we repeated with alternate shells);
- Accept upstream patches for all software/applications where available (this is an ongoing process, as vendors provide updates to their patches); and
- Review/Audit system/application performance to update non-administrative access and disable non-critical functions.
Can we detect if someone has attempted to exploit ShellShock? Has Akamai been attacked?
Because the ShellShock Vulnerability is a Remote Code Execution vulnerability at the command shell, there are many possible exploits available using the ShellShock vulnerability. Customers behind our Web Application Firewall (WAF) can enable our new custom rules to prevent exploits using legacy CGI systems and other application-level exploits. These WAF rules protect against exploits of four of the six current vulnerabilities, all that apply to our customers’ layer seven applications.
However, because ShellShock was likely present for decades in bash, we do not expect to be able to find definitive evidence — or lack thereof — of exploits.
There have been news reports indicating that Akamai was a target of a recent ShellShock-related BotNet attack. (See information about WopBot
). Akamai did observe DDOS commands being sent to a IRC-controlled botnet to attack us, although the scale of the attack was insufficient to trigger an incident or need for remediation. Akamai was not compromised, nor were its customers inconvenienced. We receive numerous attacks on a daily basis with little or no impact to our customers or the services we provide.
Akamai’s Cloud Security Research team has published
an analysis of some attack traffic that Akamai has seen across its customers for Shellshock. As the authors note in that article, the kinds of payloads being delivered using the ShellShock vulnerability have been incredibly creative, with Akamai’s researchers seeing more than 20,000 unique payloads. This creativity, coupled with the ease of the ShellShock vulnerability, is one of the many reasons that Akamai is keeping a close eye on all of the associated CVEs and continuing to update its systems and developing better protections for its customers, including custom WAF rules.
Where can I find updates on Akamai’s WAF rules?
How will Akamai communicate updates?
We will maintain this blog with interesting news from Akamai.
As the list of CVEs and implications of ShellShock expand, we do our best to only deliver verified information, sacrificing frequency of updates for accuracy.
If you have questions that aren’t addressed by one of these vehicles, please feel free to contact your account team.