Archived Content

The following content is from an older version of this website, and may not display correctly.

A year ago, the Heartbleed bug affecting the OpenSSL encryption protocol was the type of security development that transcended the tech world and into the mainstream media. The widespread use of the open-source protocol and its effect on web servers meant that millions of sites worldwide could be affected, but research from one security vendor has shown little progress in the 12 months since it made headlines.

85% of Global 2000 companies may still be vulnerable to Heartbleed
85% of Global 2000 companies may still be vulnerable to Heartbleed – Thinkstock / Nerthuz

Venafi used data from its own TrustNet certificate reputation service, and the company’s research lab found that one year later, nearly three-quarters of Global 2000 organizations with public-facing systems vulnerable to Heartbleed had failed to completely remediate the vulnerability. The company noted that its data in August 2014 found that 76% of Global 2000 organizations with public-facing systems remained vulnerable, only to improve marginally to 74% in April 2015 – a full year after the Heartbleed vulnerability was publicly disclosed.

The Heartbleed bug is a flaw in the OpenSSL internet encryption protocol. OpenSSL contains a function known as a heartbeat option: while someone is visiting a website that encrypts data using OpenSSL the computer sends and receives messages – heartbeat messages – from the server to check it is connected. The flaw means attackers can fake heartbeat messages and steal sensitive information, and at the time it was disclosed some estimates claimed as many as two-thirds of websites were hosted on servers that used the open-source encryption protocol.

Lazy Fixes

The problem, as Venfai pointed out, is that organizations have made attempts that partially remediate the Heartbleed vulnerability. The security vendor, along with many others that include analyst firm Gartner and security guru Bruce Schneier – maintain that simply patching the OpenSSL library is not enough to prevent Heartbleed-related attacks. To fully correct the situation, they all advise to:

  1. Patch the OpenSSL vulnerability
  2. Generate new encryption keys
  3. Issue and install new certificates
  4. Revoke old certificates

“The surprising part from the research findings this year is that the Heartbleed remediation steps that were taken weren’t actually driven by Heartbleed remediation efforts—this was just a secondary benefit,” noted Gavin Hill, director of threat intel for Venafi. “Instead, they were the result of impending certificate expirations. Although it is a good practice to keep short key and certificate rotation cycles, organizations should be replacing all keys and certificates to remediate Heartbleed.”

So far in 2015, only 15% of Global 2000 hosts scanned by Venafi have completed the remediation steps against Heartbleed – leaving 85% still vulnerable in some capacity.

“Organizations have either given up on properly replacing keys and certificates, most likely not grasping the full risk exposure this creates, or do not have the knowledge to understand how to complete remediation,” the company detailed in its report. “Venafi has identified 580,000 hosts belonging to Global 2000 organizations that have not been completely remediated. These partially remediated hosts have been patched against Heartbleed. However, the organizations have either performed, as described by Gartner, “lazy” remediation, failing to replace the private key, or failed to revoke the old certificate.”

As Venafi concluded, failing to replace the private key would allow an attacker to decrypt SSL traffic for a targeted host. In addition, not taking steps to revoke old certificates allows potential attackers to use these validation tools as part of phishing campaigns against a targeted organization – including its employees and customers.

“Remediating Heartbleed goes beyond simply patching the OpenSSL vulnerability,” Hill advised. “Just like user IDs and passwords are assumed compromised after a breach, so too should keys and certificates.”