Heartbleed Still Found in the Wild

Before we begin talking about Heartbleed and its impact, let's briefly understand – What is Heartbleed?

Heartbleed was discovered six years ago, and the OpenSSL vulnerability can still be found and exploited across the internet. Because of the large number of unpatched public-facing servers, 19% of global attacks target the OpenSSL Heartbleed vulnerability. Whether due to insufficient scanning or apprehension about rebooting production servers, leaving servers vulnerable to OpenSSL exploits puts customers and their data at risk. It also goes over how to tell if your processes are still using out-of-date libraries, even if you've updated them on disc.

In this article, you will delve into Heartbleed and the implications for data privacy and compliance. We will also address a few FAQs on Heartbleed, a vulnerability.

Heartbleed: A Quick Overview

OpenSSL is a free and open-source library that enables encrypted communication between a client and a server. It is open-source, so anyone can contribute to it and use it in their own server communication protocols. The vulnerable code was introduced in 2011 and made public in 2012. It wasn't until 2014 that Google researchers discovered the flaw in the code.

When a TLS/SSL-enabled server and client initiate a handshake, the client sends a 16-bit integer “message” to the server, which returns the same message to the client. This handshake is required for TLS/SSL connections to begin secure communication. The server allocates memory for the 16-bit message when the request is made.

The Heartbleed exploit sends a malformed initial handshake message to the server, which means it claims to be a certain length but is actually much shorter. For example, the client's initial handshake message claims to be 64 bytes long, but it is only 8 bytes long. When the server receives this malformed request, it reads adjacent memory values and sends them back to the client to pad the remaining bits returned to the client. This adjacent memory could contain garbage values, user credentials, private keys used to decrypt communication, or personally identifiable information (PII) like social security numbers.

Heartbleed's discovery was significant, and administrators needed to patch any server running OpenSSL 1.0.1 through 1.0 and 1.0.2 beta 1.1f as soon as possible because an exploit was already available. According to a Netcraft study, 17% of SSL servers (approximately 500,000 servers) were vulnerable to Heartbleed.

According to research, despite the fact that the Heartbleed vulnerability was reported in 2014, it is still present on many public-facing servers and user devices.

Why Administrators Don't Patch Servers

Patching vulnerable servers is the obvious solution, but doing so on crucial production servers is far more delicate and risky than doing so on a typical consumer device. Administrators will therefore plan patching for off-peak hours, which may occur weeks after a vulnerability is discovered. Data privacy is especially at risk from vulnerabilities that have working exploit codes, since attackers can use them right away without having to create any malware.

Because restarting carries a certain amount of risk, administrators frequently leave servers unpatched. The patching and rebooting schedules now in use are dangerous for two main reasons:

1. Server downtime: Even a flawless reboot can take 15 minutes or more. Services are unavailable during this time. Because large enterprises have a low tolerance for server downtime, rebooting a critical server necessitates production failover. Servers that are still in the rotation behind a load balancer may be overloaded and unable to handle traffic loads.
2. Vulnerability window: It is common for large organizations to patch and reboot servers on a monthly basis. That's weeks of servers being exposed to open threats. The larger the vulnerability window, the more likely it is that an attacker will scan and find servers vulnerable to exploits and the latest threats.

False Negatives and Manual Patching Without Rebooting

In addition to OpenSSL, the open-source community has numerous shared libraries that run on critical production servers, but these libraries, like operating system patches, must be patched to keep the server secure. To avoid compromise, some administrators manually patch servers without rebooting to avoid downtime. Patching without rebooting without the right live patching tools leaves vulnerable code in memory, but the patched version on disc and the server remain vulnerable.

When administrators run vulnerability scanners against these rebootless patched servers, the scanners detect the patched on-disk version and return a false negative. Because patched libraries running unpatched versions in memory are still vulnerable to exploits, this method of patching servers is ineffective.

Finding false negatives necessitates the use of a scanner that detects vulnerable libraries in memory rather than on disc. One such open-source scanner available to the FOSS community is UChecker by KernelCare, which can help find vulnerable servers even if they've been patched on disc.

When administrators run vulnerability scanners against these rebootless patched servers, the scanners detect the patched on-disk version and return a false negative. Because patched libraries running unpatched versions in memory are still vulnerable to exploits, this method of patching servers is ineffective.
Finding false negatives necessitates the use of a scanner that detects vulnerable libraries in memory rather than on disc. One such open-source scanner available to the FOSS community is UChecker by KernelCare, which can help find vulnerable servers even if they've been patched on disc.

Starting with version 6, the Uchecker (short for “userspace checker”) is compatible with all modern Linux distributions. The graphical illustration below depicts how Uchecker works.

Uchecker will scan your systems for outdated shared libraries with a single command:

Uchecker can check your systems for out-of-date shared libraries with just one command:

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

FAQs on Heartbleed, a Vulnerability

Conclusion

Using efficient vulnerability scanners like UChecker and implementing proper live patching management will reduce the risk associated with reboots while still keeping open-source libraries updated. It is critical that organizations accelerate the patching of vulnerable libraries, particularly those that may expose private keys and user credentials, such as OpenSSL.

Due to the issues that could arise from reboots, many servers remain vulnerable for weeks after a patch is available, but this leaves the organization out of compliance and at risk of a severe data breach.

According to Malwarebytes, thousands of websites are still vulnerable to Heartbleed, exposing anyone who connects to these websites to data privacy issues. Administrators will be able to patch these servers with the right live patching and vulnerability scanning solution.

If you have any queries, please leave a comment below, and we’ll be happy to respond to them.