Application Security
4/14/2014
01:40 PM
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 served as the InformationWeek information security reporter from 2010 until mid-2014. 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 December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
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-6477
Published: 2014-11-23
Unspecified vulnerability in the JPublisher component in Oracle Database Server 11.1.0.7, 11.2.0.3, 11.2.0.4, 12.1.0.1, and 12.1.0.2 allows remote authenticated users to affect confidentiality via unknown vectors, a different vulnerability than CVE-2014-4290, CVE-2014-4291, CVE-2014-4292, CVE-2014-4...

CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?