In April 2014, the cybersecurity community witnessed the discovery of a critical vulnerability that ruined many people’s day. Heartbleed, formally known as CVE-2014-0160 was discovered by Neel Mehta from Google’s Information Security team and Mark J. Cox from OpenSSL on April Fools’ Day, and totally spoiled the fun for everyone in the IT community.
It’s difficult to determine precisely how many devices were vulnerable to this bug, but due to the wide variety of software relying on the problematic OpenSSL library, the numbers we’re certainly high.
What is The Heartbleed Bug
Before we explain what type of flaw led to the birth of this historic bug, we would be better off if explained how it got its name first.
SSL (Secure Sockets Layer) is a cryptographic protocol that’s a predecessor to today’s TLS (Transport Layer Security) protocol, which is used for data exchange by network-relying software, such as web servers, email servers, VPNs, etc.
OpenSSL is the world’s most widely used open-source library for web application programming. In 2011 a Ph.D. student from FH Münster developed a feature that would allow two computers that were participating in an exchange of data over the network to do so more efficiently without having to repeatedly renegotiate the connection all over again.
This feature was called the “Heartbeat” and it was based on a typical request-response exchange, that is used to confirm that both sides are still open to communication using the pre-negotiated encrypted protocol. This extension’s introduction to the OpenSSL library was proposed in February 2012 by the RFC (Request for Comments), which is sort of a standard-developing entity created by IETF (Internet Engineering Task Force) to solicit feedback and input on proposed standards and protocols.
Upon the revision of the proposed change to the library done by Stephen N. Henson, one of the main developers of OpenSSL, the Heartbeat extension was introduced in OpenSSL version 1.0.1 in March 2012. Having said that, it’s obvious that Heartbleed inherited its name from the above-mentioned extension, once it was discovered to be problematic.
The Vulnerability
CVE-2014-0160, or the Heartbleed bug, is a vulnerability that affects the OpenSSL implementation of the TLS and SSL protocols. These protocols are commonly used to secure communication over the Internet, ensuring the confidentiality and integrity of sensitive data.
This vulnerability is caused by CWE-125 (Out-of-bounds Read weakness) which occurs once the vulnerable device receives the improperly crafted Heartbeat request.
Out-of-bounds read/write weakness is a very common one for programs written in C, because of manual buffer allocation. So, if we take a closer look into the structure of the buffer itself, we’ll be closer to understanding Heartbleed:
/* Allocate memory for the response, size is 1 byte
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(1 + 2 + payload + padding)This code is responsible for allocating memory for the buffer. As we can see, 1 byte is allocated for hbtype (determines if the packet is a Heartbeat request or response) and 2 bytes carry the length of the payload.
The length of the payload is inherited from the Heartbeat request. If the length of the payload was for example 4 bytes (ABCD), the length of the response is supposed to have those exact 4 bytes (ABCD). The issue arises when we receive a packet claiming that its payload is longer than the one it provides because the above-mentioned code handles the crafting of the response packet incorrectly.
Why is this?
When crafting a response packet, the victim’s computer will trust the information about payload length included in the packet, instead of verifying the length itself once having received it. There is a line of code that copies the memory buffer holding the received request, repacking it into a response message.
memcpy(bp, pl, payload);This becomes problematic because when compiling a response, it will try to copy the request payload by taking into consideration the length it was said to have written into the buffer, meaning that if it was told to have an 8 bytes long payload, but has received only 4, it will have to “invent” the remaining 4 bytes.
Now, of course, your computer can’t literally invent 4 bytes, but it will include the next 4 bytes that it finds behind the payload holding one, leading to the potential exposure of data stored in the memory.
Thankfully, it is not guaranteed that those next 4 bytes are going to hold any sensitive information. Still, on the downside an attacker can solicit up to 64kB of data in each response, meaning that his chances of retrieving something sensitive increase over a number of attempts.
The main goal for the attackers was to obtain security certificates used to encrypt the rest of the traffic between the victim’s device and the internet. With these keys, an attacker could decrypt all the network traffic that happens between the victim and the internet.
The secondary most valuable target, (in some cases perhaps even more valuable than the security certificates) would be credentials for SSH, Telnet, or other credentials that would enable the attacker to take control over the entire device.
The Magnitude of CVE-2014-0160
The impact of Heartbleed was far-reaching and potentially catastrophic. The bug affected a vast number of websites, online services, and devices worldwide, putting billions of users at risk.
OpenSSL, being an open-source library, was widely adopted, making the vulnerability particularly prevalent. The flaw remained undetected for over two years before being publicly disclosed, which increased the potential damage caused by the bug.
We need to keep in mind that many operating systems come with built-in features that use the OpenSSL library. According to The Heartbleed Bug website, this is the list of the operating systems that were potentially shipped with CVE-2014-0160:
- Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
- Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
- CentOS 6.5, OpenSSL 1.0.1e-15
- Fedora 18, OpenSSL 1.0.1e-4
- OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
- FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
- NetBSD 5.0.2 (OpenSSL 1.0.1e)
- OpenSUSE 12.2 (OpenSSL 1.0.1c)
The severity of the vulnerability prompted a significant response from organizations and individuals alike. Companies scrambled to patch their systems and revoke compromised certificates, while users were advised to change their passwords on affected platforms.
Prevention and mitigation
Upon the disclosure of Heartbleed, OpenSSL developers quickly released a patched version (OpenSSL 1.0.1g) that addressed the vulnerability. However, the incident revealed the need for better security practices across the board.
Everyone using OpenSSL-based software was advised to undertake the following measures:
- Update OpenSSL: This is the first and most logical step to take to prevent such an attack. But this step alone isn’t enough, because in cases where the security certificates have already been compromised, all further traffic can be decrypted by the attacker.
- Revoke and reissue certificates: Considering the possibility that the keys have already been compromised all admins needed to revoke and reissue SSL/TLS certificates to ensure the security for the ongoing traffic.
- Change passwords: For those who’ve gotten the worst of it, it is recommended to change their credentials that might’ve been leaked both in the initial data buffer overread and in the intercepted traffic.
Aftermath
The incident served as a wake-up call, emphasizing the importance of proactive security measures, responsible disclosure, and prompt patching. Ultimately, the incident highlighted the ever-evolving nature of cybersecurity threats and the need for continuous efforts to identify and mitigate vulnerabilities.
Unfortunately, even to this day, there are many devices on the internet still affected by this vulnerability. As you might already know, DataGrid Surface is actively scanning the web for machines susceptible not only to Heartbleed but to many other vulnerabilities as well.
Up until the 21st of January, DataGrid Surface has detected over 68000 systems still affected by CVE-2014-0160. If there’s even a shadow of a doubt regarding your organization’s security standing, we highly recommend that you check out our feed or get in touch.
Subscribe to be updated on the new content!