Heartbleed For Poets

Heartbleed For Poets And Other Must-Reads

It’s H-Day + 2 – two full days since we learned that one of the pillars of online security, OpenSSL, has contained a gaping security hole for the past two years that rendered its protections illusory.

Heartbleed For Poets
The (nerdy) Heartbleed SSL vulnerability story has jumped into the mainstream led to lots of rumination about the proper short and long term response.

As I wrote over on Veracode’s blog today: this one hurts. It exposes private encryption keys, allowing encrypted SSL sessions to be revealed. Trend Micro data suggests around 5% of one million Internet top-level domains are vulnerable.  IOActive notes that Heartbleed also appears to leave data such as user sessions subject to hijacking, exposes encrypted search queries and leaves passwords used to access online services subject to snooping, provided the service hasn’t updated their OpenSSL instance to the latest version.

In fact, its safe to bet that the ramifications of Heartbleed will continue to be felt for months – even years to come. In the meantime, there is a lot of interesting coverage and analysis of Heartbleed that’s worth reading. Here’s a list of some of the articles that I’ve found useful in understanding Heartbleed and its potential impact arranged (roughly) by topic:

Heartbleed for Poets
It’s not (that) common that the mainstream media picks up on nerdy stories like this one. (“OpenSSL installations don’t properly check bounds on TLS heartbeat!!”) But this bug is big enough and bad enough that even non-technical users need to have some familiarity with it. Enter The New Yorker, where Rusty Foster has this nicely penned and informative piece on the ‘what,’ ‘why’ and ‘how’ of Heartbleed that paints pictures with words, like this little gem:

Unlike a rusting highway bridge, digital infrastructure does not betray the effects of age. And, unlike roads and bridges, large portions of the software infrastructure of the Internet are built and maintained by volunteers, who get little reward when their code works well but are blamed, and sometimes savagely derided, when it fails.

Nicely done! The take away? OpenSSL’s understaffed development team and aged C codebase are to blame – a better staffed, better funded open source project based on a more modern programming language would have prevented Heartbleed from ever happening.  His source: Theo de Raadt over at OpenBSD, who penned a terse little critique of the OpenSSL team on Wednesday, concluding that “OpenSSL is not developed by a responsible team.”

Molly Wood (real name) over at the New York Times went looking for answers on Heartbleed and ended up…with Brian Krebs. (I’m guessing Nicole Perlroth sent her, as they reused the photo from the “Reporting from the Web’s Underbelly” story from February (now the subject of a major motion picture!) Krebs has been transformed from a security reporter to a security “researcher,” but I’m pretty sure its the same guy. 😉

Mashable has a nice Heartbleed for Non-Geeks article by Christina Warren: Why Heartbleed is the Ultimate Web Nightmare.

The bug
Though it was only revealed two days ago, Heartbleed has been taken apart and analyzed. The flaw isn’t actually all that difficult to identify or grasp, even if all you have is an intro CS course or two.

  • IOActive has a nice analysis of the vulnerability, complete with the C code and some nice explanation of what’s going on within the code and how attackers can exploit it. Long and short: the acquisition of data from adjacent memory on vulnerable OpenSSL servers is arbitrary – it might contain sensitive information like password or encryption keys in the clear, or it might contain a whole lot of junk. Still: a persistent attacker would be patient enough to keep trying until they assembled the data they want.
  • For those who can’t get enough of reading code, the blog Existentialize has a similar analysis and exegesis of the flaw here that reaches a similar conclusion as IOActive: key recovery is unlikely in casual attacks.

What for and how to
There have been lots of ‘how to’ and ‘what to do’ stories in the last 24 hours, as reporters and news outlets look for ways to keep the story going. Some are better than others. It’s worth noting the best of these, which include:

  • HelpNet Security’s article, Heartbleed: What Regular Users Need to Do, provides some useful links to Heartbleed checker sites and other publishers who are keeping a count of vulnerable sites.
  • Infoworld put together a nice, balanced list of ‘no bull’ facts about Heartbleed. Read it here.
  • Ian Paul over at PC World has a nice piece on how not to respond to the Heartbleed news. Most of this is reiterated at other sites (find out which of the web sites you frequent is affected, then change your  password – but only after you’ve confirmed that the site has updated their OpenSSL installation). He also recommends a switch to multi-factor passwords (like those from Security Ledger sponsor DUO Security) and password managers like LastPass.
  • Mashable in this article runs down the major social networking platforms to see which are affected (and thus require you to change passwords).

Attack talk
A couple of stories have looked at the question of whether the OpenSSL was known to intelligence agencies and/or organized cyber criminal groups long before it was discovered by researchers at the firm Codenomicon. Notable among them: 

  • Kim Zetter’s piece in Wired “Has the NSA been using the Heartbleed bug as an Internet peephole.”  The conclusion: possibly, but “there’s no evidence to suggest this is the case. And there are reasons why this method wouldn’t be very efficient for the NSA.”
  • Sean Gallagher’s piece in Ars Technica “Heartbleed Vulnerability May Have Been Exploited Months Before Patch” is intriguing. Admittedly: there are a lot of mark-ups and clarifications in it (the dangers of going quick to print with a developing story). But Gallagher has statements from at least once source that suggest there may have been attempts to exploit the vulnerability we now know as Heartbleed after upgrading to the vulnerable version of OpenSSL.

The Jedi Master(s) speak
What do people who really understand security have to say about Heartbleed and its import?

Internet security Obi Wan Kenobe and crypto expert Bruce Schneier has a fittingly bleak take on the Heartbleed debacle, writing:

“Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory. This means that anything in memory — SSL private keys, user keys, anything — is vulnerable. And you have to assume that it is all compromised. All of it.

‘Catastrophic’ is the right word. On the scale of 1 to 10, this is an 11.”

In some postscripts, Bruce adds some interesting third and fourth-day angles: wondering about embedded devices that might use OpenSSL and the strain on Certificate Authorities as everyone in the world tries to switch out their certs at the same time. (Johannes Ullrich at SANS ISC raised this issue with me yesterday, as well.)

More thought-provoking is Dan Kaminsky’s analysis of the Heartbleed incident. Dan takes on the sack cloth wearers within the security and open source who are now pointing fingers at OpenSSL and demanding whether the ‘TLS heartbeat’ feature (what Kaminsky refers to as ‘ping’) was really worth all the pain of Heartbleed.

“The takeaway here is not ‘If only we hadn’t added ping, this wouldn’t have happened.’ The true lesson is, ‘If only we hadn’t added anything at all, this wouldn’t have happened.’ In other words, if we can’t even securely implement Ping, how could we ever demand ‘important’ changes? Those changes tend to be much more fiddly, much more complicated, much riskier.”

The real panic in the technology community isn’t over Heartbleed, per se, Kaminsky argues, but over the thought of all the other Heartbeat like holes that might be lurking out there.

“It shouldn’t take absolute heroism, one of the smartest guys in our community, and three years for somebody to notice a flaw when there’s a straight up length field in the patch. And that, I think, is a major and unspoken component of the panic around Heartbleed,” Kaminsky writes. “The OpenSSL dev shouldn’t have written this (on New Years Eve, at 1AM apparently). His coauthors and release engineers shouldn’t have let it through. The distros should have noticed. Somebody should have been watching the till, at least this one particular till, and it seems nobody was.”

That’s a lot to think about. And, if previous infrastructure flaws are any guide (remember BEAST), we’ll have plenty of time to debate the importance of Heartbleed. Keep returning to Security Ledger for more coverage of the Heartbleed issue.

Comments are closed.