The Heartbleed vulnerability was introduced into the OpenSSL crypto library in 2012. It was discovered and fixed in 2014, yet today—five years later—there are still unpatched systems. 

This article will provide IT teams with the necessary information to decide whether or not to apply the Heartbleed vulnerability fix. However, we caution: The latter could leave your users’ data exposed to future attacks.

What is the Heartbleed vulnerability?

Heartbleed is a code flaw in the OpenSSL cryptography library. This is what it looks like:

memcpy(bp, pl, payload);

In 2014, a vulnerability was found in OpenSSL, which is a popular cryptography library. OpenSSL provides developers with tools and resources for the implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. 

Websites, emails, instant messaging (IM) applications, and virtual private networks (VPNs) rely on SSL and TLS protocols for security and privacy of communication over the Internet. Applications with OpenSSL components were exposed to the Heartbleed vulnerability. At the time of discovery, that was 17 percent of all SSL servers.

Upon discovery, the vulnerability was given the official vulnerability identifier CVE-2014-0160, but it’s more commonly known by the name Heartbleed. The latter was invented by an engineer from Codenomicon, who was one of the people that discovered the vulnerability.

The name Heartbleed is derived from the source of the vulnerability—a buggy implementation of the RFC 6520 Heartbeat extension, which packed inside it the SSL and TLS protocols for OpenSSL.

Heartbleed vulnerability behavior

The Heartbleed vulnerability weakens the security of the most common Internet communication protocols (SSL and TSL). Websites affected by Heartbleed allow potential attackers to read their memory. That means the encryption keys could be found by savvy cybercriminals.

With the encryption keys exposed, threat actors could gain access to the credentials—such as names and passwords—required to hack into systems. From within the system, depending on the authorization level of the stolen credentials, threat actors can initiate more attacks, eavesdrop on communications, impersonate users, and steal data.

How Heartbleed works

Image Source

The Heartbleed vulnerability damages the security of communication between SSL and TLS servers and clients because it weakens the Heartbeat extension.

Ideally, the Heartbeat extension is supposed to secure the SSL and TLS protocols by validating requests made to the server. It allows a computer on one end of the communication to send a Heartbeat Request message.

Each message contains a payload—a text string that contains the transmitted information—and a number that represents the memory length of the payload—usually as a 16-bit integer. Before providing the requested information, the heartbeat extension is supposed to do a bounds check that validates the input request and returns the exact payload length that was requested.

The flaw in the OpenSSL heartbeat extension created a vulnerability in the validation process. Instead of doing a bounds check, the Heartbeat extension allocated a memory buffer without going through the validation process. Threat actors could send a request and receive up to 64 kilobytes of any of the information available in the memory buffer.

Memory buffers are temporary memory storage locations, created for the purpose of storing data in transit. They may contain batches of data types, which represent different stores of information. Essentially, a memory buffer keeps information before it’s sent to its designated location. 

A memory buffer doesn’t organize data—it stores it in batches. One memory buffer may contain sensitive and financial information, as well as credentials, cookies, website pages and images, digital assets, and any data in transit. When threat actors exploit the Heartbleed vulnerability, they trick the Heartbeat extension into providing them with all of the information available within the memory buffer.

The Heartbleed fix

Bodo Moeller and Adam Langley of Google created the fix for Heartbleed. They wrote a code that told the Heartbeat extension to ignore any Heartbeat Request message that asks for more data than the payload needs.

Here’s an example of a Heartbleed fix:

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */

How the Heartbleed vulnerability shaped OpenSSL as we know it

The discovery of the Heartbleed vulnerability created worldwide panic. Once the fixes were applied, idle fingers started looking for the causes of the incident. Close scrutiny at OpenSSL revealed that this widely-popular library was maintained solely by two men with a shockingly low budget.

This finding spurred two positive initiatives that changed the landscape of open-source:

• Organizations realized the importance of supporting open-source projects. There’s only so much two people can do with their personal savings. Organizations, on the other hand, can provide the resources needed to maintain the security of open-source projects.
• To help finance important open-source projects, Linux started the Core Infrastructure Initiative (CII). The CII chooses the most critical open-source projects, which are deemed essential for the vitality of the Internet and other information systems. The CII receives donations from large organizations and offers them to OSS initiatives in the form of programs and grants.

As with any change-leading crisis, the Heartbleed vulnerability also carried a negative side-effect: the rise of vulnerability brands. The Heartbleed vulnerability was discovered at the same time by two entities—Google and Codenomicon.

Google chose to disclose the vulnerability privately, sharing the information only with OpenSSL contributors. Codenomicon, on the other hand, chose to spread the news to the public. They named the vulnerability, created a logo and a website, and approached the announcement like a well-funded marketing event.

In the following years, many of the disclosed vulnerabilities were given an almost celebrity-like treatment, with PR agencies building them up into brands, and marketing agencies deploying branded names, logos, and websites. While this can certainly help warn the public against zero-day vulnerabilities, it can also create massive confusion.

Nowadays, security experts and software developers are dealing with vulnerabilities in the thousands. To properly protect their systems, they need to prioritize vulnerabilities. That means deciding which vulnerability requires patching now, and which could be postponed. Sometimes, branded vulnerabilities are marketed as critical when they aren’t.

When that happens, not all affected parties have the time, skills, and resources to determine the true importance of the vulnerability. Instead of turning vulnerabilities into a buzz word, professionals could better serve the public by creating fixes.

Heartbleed today

Today, five years after the disclosure of the Heartbleed vulnerability, it still exists in many servers and systems. Current versions of OpenSSL, of course, were fixed. However, systems that didn’t (or couldn’t) upgrade to the patched version of OpenSSL are still affected by the vulnerability and open to attack.

For threat actors, finding the Heartbleed vulnerability is a prize; one more easily accessed by automating the work of retrieving it. Once the threat actor finds a vulnerable system, it’s relatively simple to exploit the vulnerability. When that happens, the threat actor gains access to information and/or credentials that could be used to launch other attacks.

To patch or not to patch

The Heartbleed vulnerability is a security bug that was introduced into OpenSSL due to human error. Due to the popularity of OpenSSL, many applications were impacted, and threat actors were able to obtain a huge amount of data. 

Following the discovery of the vulnerability, Google employees found a solution and provided OpenSSL contributors with the code that fixed the issue. OpenSSL users were then instructed to upgrade to the latest OpenSSL version. 

Today, however, the Heartbleed vulnerability can still be found in applications, systems, and devices, even though it’s a matter of upgrading the OpenSSL version rather than editing the codebase. If you are concerned that you may be affected, you can test your system for the Heartbleed vulnerability and patch to eliminate the risk or mitigate, if the device is unable to support patching.

Any server or cloud platform should be relatively easy to patch. However, IoT devices may require more advanced mitigation techniques, because they are sometimes unable to be patched. At this point, we recommend speaking with your sysadmin to determine how to mitigate the issue.