The Heartbleed bug was publicly announced in 2014 as a major security flaw in the encryption software OpenSSL. Security experts have rated it as one of the most critical cybersecurity vulnerabilities in the last decade. It affected major companies and services like Google, Yahoo, Dropbox, Netflix, Facebook, Amazon Web Services, Tumblr, and Intuit.
The reason for taking the Heartbleed vulnerability seriously is because it has been easy to exploit, the exposure has been around for а long time, and spotting the attacks has been tricky. The bug affects SSL (Secure Sockets Layer) /TLS (Transport Layer Security) protocols used for secure communications and privacy for a wide range of online services — including web, email, and instant messaging. It tricks web servers to transmit data stored in their memory, exposing various types of sensitive personal information and content.
Here’s an overview of what the Heartbleed bug is and how to tackle it.
Table of contents
Heartbleed Bug Security Assessment
CVSS Vector: AV:N/AC:L/AU:N/C:P/I:N/A:N
What Is the Heartbleed Bug?
The Heartbleed bug is classified within the Common Vulnerabilities and Exposures of the Standard for Information Security Vulnerability Names maintained by MITRE as CVE-2014-0160. It’s a buffer over-read – a case when a system allows data access that should be restricted.
What’s the Heartbleed vulnerability in a nutshell? It allows attackers to steal the private key of a server certificate. If the server version is vulnerable to Heartbleed, cybercriminals can retrieve the private key and impersonate the server. The consequences can be quite dire, as secure connections to the server are not possible anymore, and private information can be easily exposed.
How Does the Heartbleed Bug Work?
The mechanism behind the Heartbleed vulnerability is, in fact, not very complex. However, it entails the exploitation of inappropriate input validation in the heartbeat extension.
The SSL standard has an option to send a ‘heartbeat’ — a computer can send a message to the other end of the connection to check if the other computer is online by getting a ‘beat’ back. Attackers can use the heartbeat request functionality to send a malicious message instead of a regular one. This can make the computer on the receiving end accept and transmit secret data — including the server’s memory.
By exploiting the heartbeat option and the lack of a proper bounds check, attackers can gain access to the secret keys that encrypt personal data such as names and passwords and the transferred content.
The leakages can include primary and secondary key material, actual content, and collateral. Primary key materials are the encryption keys, which would allow decryption of traffic, while secondary key material means credentials like user names and passwords. Content can include emails, instant messages, documents, Social Security Numbers, medical records, and financial details, among others. As for collateral, it can span technical details like security mechanisms and memory addresses.
All of this data, in turn, can be used by malicious users for eavesdropping, user impersonation, and data theft. The worst part is that no traces are left during the attack — and it’s executed without any credentials. This makes it difficult to tackle the actual security instructions that may have occurred.
The Heartbleed security hole is not considered a design flaw in SSL/TLS protocol. Instead, it’s a programming error in the implementation that affects the OpenSSL cryptographic library, which provides SSL/TLS encryption to applications and services.
Scan Your Web App or API for the Heartbleed Bug
Timeline and Impact of the Heartbleed Bug
The Heartbleed bug was brought to public awareness on April 7, 2014. The same day OpenSSL released a fixed version that addresses the vulnerability.
Discovery of the Bug
The vulnerability was identified independently by two parties — by a Codenomicon security engineering team consisting of Riku, Antti, and Matti, and by Neel Mehta from Google Security, who was the one to report it to the OpenSSL team.
The Codenomicon security research team discovered the huge security bug during their efforts to boost the SafeGuard feature of their Defensics security testing platform. They reported it to the Finish Transport and Communications Agency to inform OpenSSL, but that already happened in the meantime.
An engineer from the Finnish cyber security company Synopsys Software Integrity Group named the bug ‘heart bleed’ and created a dedicated website to inform the public.
How the Bug Occurred
OpenSSL is one of the best-known SSL implementations, which enables systems to communicate with SSL encryption technology. The open-source project has been around since 1998 and has gained massive popularity. It is mostly developed by volunteers, with a minimum of permanent active developers on board who review the contributions of the developer’s community to the project.
The 31-year-old German developer Robin Seggelmann added the faulty Heartbeat feature — lacking a validation process of a variable containing length — to an experimental version of OpenSSL in late 2011. Then his features’ submission passed through OpenSSL review, but the developer there also didn’t catch the flawed code.
The vulnerable versions of OpenSSL have been around for more than two years — since March 2012 — before the bug was discovered and announced. Therefore, systems running earlier versions of OpenSSL (before 1.0.1) were not vulnerable.
In 2014, two other major flaws in SSL were discovered in Apple’s SSL implementation and another one used by open-source operating systems.
The impact of the Heartbleed bug has been widespread and is thus considered critical. The consumer sites using OpenSSL display a ‘lock’ icon next to the address and an ‘s’ in the web address (at the end of ‘https’). It signifies the website encrypts and protects private data.
As of April 2014, the open source web servers Apache and Nginx, which use OpenSSL, made up two-thirds of the market share of all active sites online. This gives an idea of the massive scope of the Heartbleed vulnerability. It affected not only digital companies but also public bodies like the Canada Revenue Agency.
Since attacks leave no traces in the logs, intrusion detection and estimation of the actual exploitation attempts and successes of the Heartbleed bug are difficult. Users are furthermore users able to take specific protective actions since the problem was with vulnerable servers. First, however, users needed to install updates and change passwords to ensure their credentials wouldn’t be stolen whenever the bug was fixed in a system.
As a result of this critical bug, digital companies and the Internet community as a whole took direct steps to address similar vulnerabilities.
Fundraising started via the Core Infrastructure Initiative by the non-profit Linux Foundation. The goal of the funds was to support widely used open-source software like OpenSSL, which had no financing. Some of the contributors included Amazon, Microsoft, Google, and Facebook.
Hewlett-Packard had a separate cyber security initiative too.
How to Prevent Heartbleed
Follow this guide to prevent the Heartbleed attack:
Update OpenSSL to the latest version. The following versions are known to have fixed the Heartbleed vulnerability:
- OpenSSL 1.0.1g
- OpenSSL 1.0.0 (not affected)
- OpenSSL 0.9.8 (not affected)
apt-get update; apt-get upgrade # Debian / Ubuntu yum update # RHeL / CentOS pacman -Syu # Arch Linux
This step is key because if you’re running vulnerable versions of OpenSSL, the risk of attacks remains.
Do you want to check the security of your web app or API? Then, you can try out Crashtest Security’s Vulnerability Testing Software to spot cybersecurity vulnerabilities in no time.