Skipping a Heartbeat: The Analysis of the Heartbleed OpenSSL Vulnerability
Software vulnerabilities exist – it’s a fact of life that we all have to live with, and if we’re both lucky and diligent enough, we can patch it before any cybercriminals can exploit it. That isn’t always the case, but thankfully that’s the exception, not the rule.
However, news broke out recently of a vulnerability involving the Heartbeat extension of OpenSSL, an open-source toolkit that helps webmasters and developers make transactions safer and more secure. This vulnerability, if taken advantage of – and there’s no way of knowing if cybercriminals already have, due to the nature of the vulnerability itself – could mean the compromise of a lot of transactions on websites and applications that use OpenSSL.
What is the Heartbeat OpenSSL Extension?
OpenSSL introduced an extension called Heartbeat around December 2011, with its 1.0.1 build release as defined in the RFC 6520 TLS/DTLS Heartbeat Extension. This extension’s function was to help avoid reestablishing sessions and allow for a mechanism by which SSL sessions could be kept alive for longer. The RFC proposed a HeartbeatRequest which must be answered with a HeartbeatResponse message. This results in a conservation of network resources, resources that would generally be used for full session renegotiation.
It’s to note here that OpenSSL is used by many websites and software, from open source servers such as Apache and nginx to email servers, chat servers, virtual private networks (VPNs) and even network appliances.
As such, it’s reasonable to assume that the Heartbeat extension is very widely used, thus making the scope of this vulnerability quite wide indeed.
Understanding The Heartbleed Bug
The vulnerability, dubbed as the Heartbleed Bug, exists on all OpenSSL implementations that use the Heartbeat extension. When exploited on a vulnerable server, it can allow an attacker to read a portion — up to 64 KB’s worth — of the computer’s memory at a time, without leaving any traces.
This small chunk of memory could contain user-critical personal information — private keys, usernames, passwords (in cleartext in a lot of cases), credit card information, and confidential documents for example. The attacker could request this chunk again and again in order to get as much information as they want – and this bug could be exploited by anyone on the Internet, anywhere.
A major Internet content provider was also affected by this bug and they fixed it quickly and diligently. But before it was fixed, some malicious actors had already stolen sensitive information.
At its core, the Heartbleed bug is a simple and usual programming error, the kind of which leads to security issues. In simplified terms, it returns memory contents without checking on how much it actually reads and returns.
As such, the user can ask for more information, and it gives the user more from the memory without checking to see if the user is in fact authorized to see that information. There is a payload length field that can be manipulated to grab the memory contents by tricking the server.
Figure 1. Payload Length of the Heartbleed Bug
This vulnerability has been assigned with the identifier CVE-2014-0160.
Since this attack leaves no traces at all – it is an abuse of a bug in the code – it is hard to say if it’s being exploited in the wild. We will be monitoring our sensors for any such behavior.
Which versions of OpenSSL are affected? Am I affected?
As per the OpenSSL advisory:
“Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.”
Any other versions of OpenSSL are NOT affected by this bug. If you compiled your applications with any of these versions, then you may be affected.
Users can also check if their server is affected by the Heartbleed vulnerability with this website.
The fixed version is 1.0.1g, which was released on April 7, 2014.
What should I do if I am affected?
Affected users must upgrade to OpenSSL version 1.0.1g which has the Heartbleed bug fixed.
If an upgrade is not possible you must recompile your applications to turn off the Heartbeat extension. This can be accomplished by using the -DOPENSSL_NO_HEARTBEATS flag.
Trend Micro Solution
Trend Micro Deep Security customers should upgrade to DSRU-14-009 and assign the following rules:
- 1006010 – Restrict OpenSSL TLS/DTLS Heartbeat Request
- 1006011 – OpenSSL TLS/DTLS Heartbeat Information Disclosure Vulnerability
- 1006012 – Identified Suspicious OpenSSL TLS/DTLS Heartbeat Request