Application Security
4/14/2014
01:40 PM
Connect Directly
RSS
E-Mail
50%
50%

Akamai Withdraws Proposed Heartbleed Patch

As researchers demonstrate OpenSSL bug exploits that retrieve private keys, Akamai rescinds a patch suggestion for the SSL/TLS library after a security researcher punches holes in it.

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).

Mathew Schwartz is a freelance writer, editor, and photographer, as well the InformationWeek information security reporter. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cumulonimbus
50%
50%
cumulonimbus,
User Rank: Apprentice
4/14/2014 | 4:34:33 PM
Dark Corners of Security
SSL encryption is just one small aspect of security in this digital age, albeit an important one, since the padlock icon is probably the dominant symbol of trust in the mind of an online consumer, about to part with her coveted credit card information. However, if you consider all the online accounts she may have, and how many passwords that would be to remember individually (she has to write them down somewhere) and the fact that most allow login using an email address, then the possibility of duplicating passwords over multiple logins is quite likely (or just one, say Facebook?). Therein lies a serious breach issue.  As a responsible designer do you ensure your client's passwords are stored in the database in encrypted form?

Now consider the shared information in the "bright" web. Advertizing (somewhat) miraculously appears on the website she next visits relating to good/services searched for on another. But wait, what if this is a shared computer, is it now just simply a harmless random ad, or is her personal information being unwittingly disclosed?
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Moderator
4/14/2014 | 3:47:51 PM
The kind of assurance that is not reassuring
Akamai CSO Andy Ellis says " we had a bug" in withdrawing Akamai's OpenSSL HeartBleed patch. It  seems like more than a bug. It seems like a fundamentally flawed approach to security. This is not reassuring.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
DevOps’ Impact on Application Security
DevOps’ Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, it’s a “developers are from Mars, systems engineers are from Venus” situation.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5316
Published: 2014-09-21
Cross-site scripting (XSS) vulnerability in Dotclear before 2.6.4 allows remote attackers to inject arbitrary web script or HTML via a crafted page.

CVE-2014-5320
Published: 2014-09-21
The Bump application for Android does not properly handle implicit intents, which allows attackers to obtain sensitive owner-name information via a crafted application.

CVE-2014-5321
Published: 2014-09-21
FileMaker Pro before 13 and Pro Advanced before 13 does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-2319...

CVE-2014-5322
Published: 2014-09-21
Cross-site scripting (XSS) vulnerability in the Instant Web Publish function in FileMaker Pro before 13 and Pro Advanced before 13 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-3640.

CVE-2014-6602
Published: 2014-09-21
Microsoft Asha OS on the Microsoft Mobile Nokia Asha 501 phone 14.0.4 allows physically proximate attackers to bypass the lock-screen protection mechanism, and read or modify contact information or dial arbitrary telephone numbers, by tapping the SOS Option and then tapping the Green Call Option.

Best of the Web
Dark Reading Radio