It’s now more than seven years since the discovery of Heartbleed, a dangerous OpenSSL exploit that affected millions of systems when it was discovered. That’s a very long time ago, so why are we posting another article about Heartbleed?
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. If you’re patching your systems on time, every time, you have nothing to worry about.
But what if you missed a patch somewhere?
As it turns out, it is still common for systems to be vulnerable to Heartbleed. In this article, we give a quick overview of Heartbleed and its history and point 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.
1. What exactly is the “Heartbleed bug”? A quick overview
2. Heartbleed is still out in the open
3. Patching is the solution… but also the problem
4. Checking for unpatched libraries with uChecker
5. It’s worth double-checking on Heartbleed
What exactly is the “Heartbleed bug”? A quick overview
In 2014, researchers discovered that OpenSSL versions 1.0.1 through to 1.0.1f included a type of memory handling bug called a missing bounds check. In other words, OpenSSL does not check that 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 that indicates that the connected server is still alive.
The net result is that 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 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. 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.
Patches for OpenSSL was 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 record for 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, your organization 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.
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 can 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 patch run. That 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 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 this 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. Seven years after Heartbleed was discovered, it is by no means impossible that your organization has neglected to thoroughly patch to protect against Heartbleed – or 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 and libraries stored on disk.
That 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
Seven 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 have gaps in their response to Heartbleed.
If you don’t currently deploy a live, automated 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.