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 in 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.

“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.

SSL certificates must also be revoked and replaced with new ones. With SSL certificates installed with the affected version of OpenSSL, the private keys could be potentially exposed. With no specific method of knowing which existing certificates are affected, new SSL certificates must be generated.

End-users should also consider changing their passwords for their online accounts as the Heartbleed bug exposes sensitive information such as usernames and passwords. To avoid compromised accounts, users must reset all their passwords as soon as they are prompted to do so. They should also monitor for any suspicious activity involving their accounts, especially those financially related.

Trend Micro Solution

Trend Micro Deep Security customers should upgrade to DSRU-14-009 and assign the following rules:

It is also possible to check for attempts to exploit the vulnerability through visibility and control of what goes on within a network. Through Deep Discovery, it is possible to monitor a web server and check for SSL/TLS-related traffic through the rule CVE-2014-0160-SSL_HEARTBEAT_EXPLOIT. Once found, Deep Discovery searches for Heartbeat message responses and checks for characteristics that indicate an exploit, specifically those related to the number of consecutive responses, the amount of information being echoed back, and others. This makes it possible to detect: attacks against a monitored server, as well as attempts to exploit the Heartbleed vulnerability from within a monitored network. This new Deep Discovery rule is released and automatically applied as part of the automatic update process for Deep Discovery.

Update as of April 14, 2014, 7:41 A.M. PDT

Client applications are also vulnerable to the Heartbleed vulnerability. If they connect to a malicious server, the Heartbleed bug can be exploited to read the client system’s memory. Last April 11th, Trend Micro released the following rules to protect customers using Deep Security and IDF from this exploit: