It’s been six years since Heartbleed was first discovered, and the OpenSSL vulnerability can still be found and exploited across the internet. As a matter of fact, 19% of global attacks target the OpenSSL Heartbleed vulnerability due to the volume of unpatched public-facing servers. Whether it’s from poor scanning or fear of rebooting production servers, leaving servers open to OpenSSL exploits leaves customers and their data at risk. This article takes a deep dive into Heartbleed and the threat it has on data privacy and compliance. It also discusses how to identify if your processes still use outdated libraries, even if you’ve updated them on disk.

A Brief Overview of Heartbleed #

OpenSSL is an open-source library for facilitating encrypted communication between a client and a server. Because it’s open-source, anyone can contribute to its codebase and use it in their own server communication protocols. The vulnerable code was added in 2011 and released in 2012. It wasn’t until 2014 that researchers at Google discovered the vulnerable code.

When the initial handshake between a TLS/SSL enabled server, and client is made, the client sends a 16-bit integer “message” to the server and the same message is sent back to the client. This initial handshake is necessary for TLS/SSL connections to initiate secure communication. When the request is made, the server allocates memory for the 16-bit message.

The Heartbleed exploit sends a malformed initial handshake message to the server, meaning a message that claims it consists of a certain length, but the message is actually much smaller. For example, the client’s initial handshake message claims that the length is 64 bytes but it’s only 8 bytes. When the server receives this malformed request, it pads the remaining bits returned to the client by reading adjacent memory values and sending it back to the client. This adjacent memory could be garbage values, or it could be user credentials, private keys used to decrypt communication, or personally identifiable information (PII) such as social security numbers.

The discovery of Heartbleed was significant, and it was imperative for administrators to patch any server using OpenSSL 1.0.1 through 1.0 and 1.0.2 beta 1.1f as fast as possible as an exploit was already available. A Netcraft study indicated that 17% of SSL servers (approximately 500,000 servers) were vulnerable to Heartbleed. As research suggests, even though the Heartbleed vulnerability was reported in 2014, it still remains an issue on many public-facing servers and user devices.

Why Administrators Fail to Patch Servers #

The obvious fix for a vulnerable server is to patch it, but patching critical production servers is much more delicate and risky than a standard user device. For this reason, administrators will schedule patching during off-peak business hours, which could be weeks after a vulnerability is found. Vulnerabilities with exploit code available are especially dangerous to data privacy as these vulnerabilities can be immediately exploited and don’t require attackers to develop their own malware.

Administrators often leave servers unpatched due to the risk involved with rebooting. Current patching and reboot schedules are risky for two primary reasons:

1. Server downtime: Even a smooth reboot with no issues can take 15 minutes or longer. During this time, services are unavailable. Large enterprises have a low tolerance for server downtime, so rebooting a critical server requires failover in production. Failover or servers still in the rotation behind a load balancer could be overloaded and can’t handle traffic loads.

2. Window of vulnerability: It’s common for large organizations to patch and reboot servers monthly. That’s weeks of leaving servers vulnerable to open threats. The larger the window of vulnerability, the more likely it is that an attacker could scan and find servers open to exploits and the latest threats.

Rebootless Manual Patching and False Negatives #

In addition to OpenSSL, the open-source community has numerous shared libraries that run on critical production servers, but these libraries must be patched along with operating system patches to keep the server secure. To avoid compromise, some administrators manually patch servers without a reboot so that downtime is not a risk. Without the right live patching tools, patching without a reboot leaves vulnerable code in memory, but the patched version on disk and the server remains vulnerable.

When administrators run vulnerability scanners against these rebootless patched servers, the scanners return a false negative by detecting the patched on-disk version. Patched libraries running unpatched versions in memory are still vulnerable to exploits, so it’s an ineffective way of patching servers.

Finding false negatives requires a scanner that detects in-memory vulnerable libraries instead of using on-disk results. UChecker by KernelCare is one such open-source scanner available to the FOSS community to help them find vulnerable servers even if they’ve been patched on disk.

It’s free software, built with JSON, and open to redistribution and/or modification under the terms of the GNU General Public License. Uchecker detects processes that use old (i.e., unpatched) shared libraries. It detects and reports not-up-to-date shared libraries that are being used by running processes. With KernelCare’s scanner, administrators get the process ID and name of the vulnerable shared library as well as the library’s build ID. This information can be used to identify vulnerabilities and the patches needed to remediate the issue.

The Uchecker (short for “userspace checker”) works with all modern Linux Distributions starting from version 6. The following graphical illustration shows how Uchecker works.

Using just one command, Uchecker will scan your systems for outdated shared libraries:

curl -s -L https://kernelcare.com/checker | python

Visit ​UChecker’s Github page ​ to learn more or watch the demo of how it works .

Conclusion #

Using efficient vulnerability scanners like UChecker and implementing proper live patching management will eliminate much of the risk associated with reboots while still keeping open-source libraries updated. It’s critical that organizations speed up patching of vulnerable libraries, especially ones that could potentially disclose private keys and user credentials such as OpenSSL. Currently, many servers remain vulnerable for weeks after a patch is available due to the issues that could arise from reboots, but it leaves the organization out of compliance and at risk of a severe data breach. Malwarebytes reports that thousands of websites are still vulnerable to Heartbleed, leaving anyone who connects to these websites open to data privacy issues. The right live patching and vulnerability scanning solution will help administrators patch these servers and stop the disclosure of their customers and protect them from identity theft and account takeover.

If you have any questions or feedback, feel free to leave a comment.