Why your servers can still suffer from (a) Heartbleed – and what to do

March 22, 2023 - TuxCare PR Team

It’s been about a decade since the discovery of Heartbleed, a dangerous OpenSSL exploit that affected millions of systems – and a vulnerability that made its way into popular news media.

History, right? Technology moves fast… ten years is a long time… and that vulnerability is long gone, right?

Wrong.

We’re posting yet another article about Heartbleed because, guess what, it’s still with us. Yes, given how quickly a patch was released, and taking into account the fast pace of technology development, Heartbleed really should have faded into the background by now.

And, if you’ve patched your systems on time, every time, you have nothing to worry about.

But what if you missed a patch somewhere? What if your company recently merged with another company where patching wasn’t up to scratch? Or what if that brand-new technology solution contains a chunk of outdated code?

As it turns out, it is still commonplace for systems to be vulnerable to Heartbleed. In this article, we give a quick overview of Heartbleed and its history. We’ll also point you to recent research that shows that countless systems are still at risk of an attack enabled by a Heartbleed exploit.

We also outline how you can easily check whether you have OpenSSL libraries vulnerable to Heartbleed, and what you can do to ensure that you have watertight protection against this dangerous vulnerability.

What Exactly Is the “Heartbleed Bug”? A Quick Overview

In 2014, researchers discovered that OpenSSL versions 1.0.1 to 1.0.1f included a type of memory-handling bug called a missing bounds check. In other words, the OpenSSL code did not check that the data entered into memory does not exceed the allocated buffer size.

An attacker can, therefore, trick the OpenSSL service into allocating a 64KB buffer, only to send data that exceeds the buffer size. By doing that, the attacker can leak (or bleed) data from the victim’s machine in 64KB increments. That’s just a brief description – for details of the exploit you can read CSO Magazine’s in-depth article here.

The flaw was called Heartbleed due to the need to “bleed” data bit by bit, and because the attack occurs during what’s called a “heartbeat” – the pulse message that is sent between two servers to confirm that the connected server is still alive.

The opportunities for exploiting the Heartbleed vulnerability were broad and severe. Attackers can steal anything from cryptography keys and user credentials right through to private documents and communications. An attacker can accomplish all of that without being in possession of access credentials – and without even leaving a trace.

While 64KB doesn’t sound like much, it opens the door to large breaches. In one startling example of a Heartbleed hack, one attacker managed to steal 4.5 million patient records from Community Health Systems in 2014.

Heartbleed Is Still Out in the Open

Okay, so that was in 2014. Why is Heartbleed still worth writing about? Simply because of the vast number of applications and servers that rely on OpenSSL which, mixed with the tendency to patch inconsistently, leave us with a large number of services that are still vulnerable.

At the time Heartbeat was discovered, Netcraft reported that about 17% of secure web servers were vulnerable, including some of the world’s most popular services. That’s a huge number of servers.

Patches for OpenSSL were released as soon as the vulnerability was announced, but it doesn’t mean that Heartbleed has been patched into history.

Security researchers are still pointing to risks around Heartbleed. Recently, Japan’s technology giant NTT flagged in a research report that Heartbleed is one of the key reasons why OpenSSL is still one of the services most commonly targeted by hackers.

Likewise, in November 2020, a researcher at the SANS Internet Storm Center used the Shodan Search Engine to discover that over 200,000 machines are still vulnerable to CVE-2014-0160, the official identifier of the Heartbleed vulnerability. Through a validation process, the researcher found that Shodan was mostly correct in its assessments.

Clearly, while mitigation is available, Heartbleed is still a problem. If you’re using TuxCare’s library patching service, LibraryCare, you have little to worry about, as your libraries will always be up to date. But, in the absence of an automated and rebootless library patching solution, you must review how your operations may still be vulnerable to Heartbleed due to an OpenSSL library vulnerability.

Patching Is the Solution… but Also the Problem

The reason why Heartbleed is still out there is by no means due to a lack of patches. Most services relying on OpenSSL will have a patch available to remove the Heartbleed threat. Apply the patch and the Heartbleed threat is gone, as simple as that, the theory goes.

Yet it’s not quite that simple for several reasons. In the enterprise environment, patching isn’t a matter of simply triggering a patch and restarting a service or device. Patching requires planned downtime and significant resources, involving time from a range of experts, including sysadmins, DBAs, and Linux administrators. Many problems arise in the process:

Uncertainty about which libraries are updated: In running a patch process, a degree of automation is often involved and it can leave sysadmins unsure of which libraries were patched during the process. This can lead to extensive, unnecessary reboots and additional downtime – which can act as a break on comprehensive patching.
Not patching consistently: Another danger is that some libraries may not be patched simply because administrators are not aware that these libraries need to get patched. A full and comprehensive catalog of libraries can be difficult to establish and all it takes for a breach is a single unpatched library. Manual patching can also quickly lead to missed libraries.
Vulnerability window: Patches are often released quickly – but applied less quickly. The reason for this is the difficulty in planning for downtime, and the challenges of getting all the technical ducks in a row to apply a patch. This leaves a window between the point in time a vulnerability was reported and when that vulnerability is patched by the end-user. During this window, your organization’s systems will be vulnerable to attack.

Clearly, patching can quickly become a hit and miss affair. Years after Heartbleed was discovered, it is still by no means impossible that your organization has neglected to thoroughly patch to protect against it.

It’s also possible that, in the meantime, you’ve acquired technology that still carries the critical OpenSSL flaw.

Checking for Unpatched Libraries with Uchecker

If you’re a sysadmin and you’re wondering whether your libraries are consistently patched, one of the tools you should consider using is uChecker – a free, GNU-licensed tool developed by the team behind TuxCare.

uChecker helps you check whether your libraries are patched against the Heartbleed vulnerability, generating an easy-to-read report detailing which libraries are not up to date. uChecker can scan libraries in memory as well as libraries stored on disk.

This is an advantage over other scanners that will fail to spot unpatched libraries in memory. It is easy to install uChecker – simply view the GitHub page here.

$ curl -s -L https://kernelcare.com/uchecker | sudo python

Once you’ve done a scan with uChecker, you can proceed to patch any OpenSSL services that are still vulnerable to Heartbleed.

As a matter of security, you should thoroughly check code you download from the internet before running it in your systems. The command above can, and should, be separated into two – one to download the code which you would check, and then another to actually run it. Shown above is just a convenient way of running uChecker, not the best security practice.

It’s Worth Double-Checking on Heartbleed

Years after the emergence of Heartbleed, it is without a doubt worth checking that your servers are thoroughly protected against this dangerous threat. We’ve pointed to two examples of how recent research underlines that organizations still have gaps in their response to Heartbleed.

If you don’t currently deploy an automated live patching tool, we recommend that you run uChecker – it’s a free and easy tool that will quickly highlight if you have servers that are still vulnerable to Heartbleed.

Either way, keeping a close eye on OpenSSL is critical. It’s an important security layer, yet – at the same time – it’s been one of the most exposed pieces of software, with 202 vulnerabilities discovered from its release until the time of writing – of which Heartbleed was just one.

And don’t forget – TuxCare’s LibCare will keep your libraries, including OpenSSL, up to date – without fuss. Read more about LibCare here.

Summary