It’s Been Three Years: Why Hasn’t Heartbleed Bled to Death?

It's been three years since news first broke about the Heartbleed vulnerability. It was a wakeup call that really focused the entire industry on the critical impact of compromised keys and certificates. Even so, hundreds of thousands of publicly accessible Internet devices are still vulnerable to the flaw. So why hasn’t all the hype led to full remediation? I would venture that it’s because many organizations have found it more difficult than they imagined to replace all of their keys and certificates. And because they can’t manage these encryption assets effectively, they probably don’t have any way of knowing if the Heartbleed vulnerability is being used against them.

It's important that affected companies don't find themselves still exposed to Heartbleed one year from now. They should use the bug's third anniversary to patch the vulnerability and do their due diligence when it comes to protecting their encryption keys.

On 1 April 2014, Neel Mehta of Google's security team secretly reported a vulnerability in OpenSSL, an open-source cryptographic library used by web servers like Apache and nginx, email servers, virtual private networks, and others. Dubbed "Heartbleed," the bug affected more than 500,000 websites at the time of its disclosure. All those services were susceptible to data leaks of four types of memory content: "primary key material," i.e. encryption keys; "secondary key material," i.e. users' credentials for the vulnerable services; "protected content," i.e. data handled by vulnerable services; and "collateral," i.e. other details exposed in the attack.

Tim Bedard, Director of Threat Intelligence and Analytics at Venafi, explains that Heartbleed's exposure of secret keys opens numerous attack vectors for nefarious individuals:

"The compromise of keys and certificates allows bad attackers to eavesdrop on communications, steal data directly from services and users, and impersonate services and users. These are the crown jewels, the encryption keys themselves. Leaked keys allow an attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will."

Recovering from Heartbleed requires patching the vulnerability, revoking the compromised keys, and reissuing and redistributing new keys. Given the severity of the bug, many organizations rushed to apply these fixes after they learned about the security hole. But plenty of others didn't. Around the flaw's first anniversary, Venafi found that most Global 2000 organizations remained vulnerable to Heartbleed. Nearly three years later, a report released by Shodan indicated that upwards of 200,000 publicly accessible Internet devices had yet to receive a patch for the issue.

It's up to organizations to protect themselves and their customers' data. Bedard acknowledges this responsibility. As a result, he feels that so many devices remain vulnerable to Heartbleed because companies' certificate management strategies don't match today's business pressures.

As he notes:

"Combined with the shared volume of machine identities in today’s global extended enterprise, organizations are ill-equipped to revoke and reissue their compromised keys and certificates in a timely fashion. With a fully automated orchestration platform organizations can quickly and easily revoke, reissue, and validate their new keys and certificates at scale."

All those publicly accessible Internet devices don't need to still be vulnerable in 2018. Organizations who own those assets should patch the bug and complete the process of obtaining new keys and certificates. They should then use a solution such as the one described by Bedard that allows them to discover, securely distribute, and renew their certificates on a timely basis. 

Are you prepared to protect your keys and certificates in the post-Heartbleed world?