Akamai Withdraws Proposed Heartbleed Patch

Fallout from the Heartbleed vulnerability continues, with Akamai rescinding a patch that it claimed would have blocked exploits designed to target the OpenSSL flaw itself.

Akamai CSO Andy Ellis warned Sunday that code recently published by his firm to guard against attempts to use the Heartbleed vulnerability to steal OpenSSL private keys, and which Akamai has used for 13 years to protect its customers, was flawed and shouldn't be trusted.

"In short: we had a bug," Ellis said in a blog post. That admission invalidated earlier assurances that Akamai didn't believe the Heartbleed vulnerability would put any keys stored by Akamai at risk, due to the company's "custom secure allocation scheme."

The vulnerability in that custom allocation scheme stemmed from an RSA key made of six critical values, but Akamai's code securing only three of them. If an attacker were able to recover even one of the three insecure values from memory, Ellis said, it could have calculated all six of the critical values and cracked the key.

Akamai published the proposed patch for OpenSSL on Friday and invited the OpenSSL community to use it in crafting a permanent patch for the more than 53% of web servers -- hosting more than half a billion websites -- that rely on OpenSSL. "It adds a 'secure arena' that is used to store RSA private keys... this patch is a variant of what we've been using to help protect customer keys for a decade," Akamai principal security engineer Rich Salz said in an email to an OpenSSL newsgroup.

[Heartbleed won't be cured by patches alone. See Heartbleed Will Go On Even After The Updates.]

But Salz also had cautioned that the 802 lines of code released by Akamai shouldn't be considered ready for prime time. "This should really be considered more of a proof of concept than something that you want to put directly into production." Akamai would be happy to help make that happen. "Let me restate that: do not just take this patch and put it into production without careful review."

Shortly thereafter, flaws in Akamai's code were spotted by the independent security researcher Willem Pinckaers, who reported finding and confirming the allocation scheme bug after just 15 minutes of code review. "They should not be sending out non-functional, bug ridden patches to the OpenSSL community, while claiming they protected Akamai against the Heartbleed attack," he said on his website. Pinckaers also questioned whether Akamai's code had ever been reviewed by a security engineer.

In response to that report, Ellis said Sunday that Akamai's proposal would have been ineffective at blocking Heartbleed exploits, and that the company would immediately reissue "all customer SSL keys/certificates." He noted that, while some would be released quickly, others would have to be validated by certificate authorities and would take longer to release.

Akamai, as of Monday morning, did not respond to a request for comment about how long it might take for all affected customers to have reissued certificates in place.

It's also unclear how many of Akamai customers might be at risk as a result of the flaw in the company's code. "Most websites that use Akamai aren't impacted by Heartbleed -- as Akamai charges extra for HTTPS, many don't use it," Christopher Soghoian, principal technologist and senior policy analyst for the ACLU's Speech, Privacy, and Technology Project, said via Twitter. "No crypto, no lost keys."

Akamai, of course, isn't the only business to report that it's likely vulnerable to the OpenSSL bug. Other sites, including Pinterest, Tumblr, Yahoo, and Google, have -- or are putting -- related patches in place. But one ongoing cause for concern will no doubt be older versions of Android, since only the latest version is immune to the flaw.

New research has also suggested that the Heartbleed vulnerability is far from academic. An open challenge issued Friday by CloudFlare -- which said that it believed private keys couldn't be stolen using the Heartbleed vulnerability, but it wanted to make sure -- resulted in a successful exploit just nine hours later.

"It turns out we were wrong. While it takes effort, it is possible to extract private SSL keys," CloudFlare said in a blog post late Friday. "Our recommendation based on this finding is that everyone reissue and revoke their private keys. CloudFlare has accelerated this effort on behalf of the customers whose SSL keys we manage."

Code for one such exploit -- ranked as the seventh-fastest attack for stealing a private key via the Heartbleed vulnerability -- was published over the weekend.

By Monday, the Canada Revenue Agency had warned that the bug appeared to have been exploited to steal social insurance numbers belonging to 900 Canadians, and the agency was in the process of patching the flaw on its servers.

"Social Insurance Numbers (SIN) of approximately 900 taxpayers were removed from CRA systems by someone exploiting the Heartbleed vulnerability," the CRA said in a press release. "We are currently going through the painstaking process of analyzing other fragments of data, some that may relate to businesses, that were also removed."

One takeaway from both the Heartbleed flaw, which persisted for years before being found, and Akamai's long-used but buggy code for securing customers' SSL keys is that putting effective cryptography in place remains challenging. "Crypto is hard; actually secure crypto even harder," computer security researcher David Litchfield said via Twitter.

Cyber-criminals wielding APTs have plenty of innovative techniques to evade network and endpoint defenses. It's scary stuff, and ignorance is definitely not bliss. How to fight back? Think security that's distributed, stratified, and adaptive. Read our Advanced Attacks Demand New Defenses report today (free registration required).