Heartbleed Exploit

Heartbleed Exploitation gets its name from the heartbeat in attack client and server as there is a heartbeat pulse that communicates to "Yes, I am still here".

Discovery of Heartbleed

This catastrophic exploit was discovered by Neel Mehta, an employee of Google Security in March and had to do line-by-line audit of OpenSSL code. Later, Codenomicon, a finnish company was working on their pentesting software called Safegaurd and when they decided to test it, they discovered that they could gain enormous amount of data. They were the ones who named it "Heartbleed" and also publicized their discovery on April 7, 2014.

Heartbleed Exploit's Working

CVE-2014–0160 is missing its bound check before a memory copy (memcpy) call. The call requires three parameters.

memcpy(bp, pl, payload);

The first bit "bp" is the final destination of the data on the server that needs to be copied. The second bit "pl" is the location of the data that needs to be copied, which means the actual data the client sent as heartbeat The third bit "payload" is the amount of data that is required when the copy is attempted, which means "how big the payload is".

There is nothing like "empty memory", so "bp" is never actually empty. The computer treats it as empty because it has been marked for deletion, until it will be filled up with new data, "bp" is just sitting with old data that will be overwritten. This is how memcpy should actually work unless the payload has been altered. If the payload has been saying 64Kb when in reality it is 0Kb. So memcpy creates a strip of 64Kb at bp where the old data is waiting to be overwritten but none of that data gets overwritten because there is nothing to replace it with since "pl" is empty. This means that whatever data is in "bp" prior to the heartbeat gets passed back to the client.

In short: The call uses a non-sanitized user input, and the attacker can trick the OpenSSL into allocating a buffer of 64Kb and by doing so the attacker can copy buffer more than that is necessary. This will result into the leaking of victim's system's memory.

This vulnerability allows the attack to extract memory contents from a webserver during the heartbeat and using this, an attacker can extract the private keys used for SSL/TLS

What makes it unique?

This bug was found in the implementation of the heartbeat (RFC6520) in the transport layer security protocols, and it is unique as it has left a lot of private keys exposed on the internet and the attack leaves no trace which makes it a dangerous exploit as well.

What is affected?

According to Netcraft's April 2014 Web Server Survey, the combined market share of Apache and Ngnix on Internet was over 66%

Open-source web servers like Apache and ngnix widely use OpenSSL and OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable and the release of OpenSSL 1.0.1g fixed the bug

Some operating system distributions that have been shipped with potentially vulnerable OpenSSL versions:

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 fix

* Read type and payload length first */

if (1 + 2 + 16 > s->s3->rrec.length)

return 0;

/* silently discard */

hbtype = *p++;

n2s(p, payload);

if (1 + 2 + payload + 16 > s->s3->rrec.length)

return 0;

/* silently discard per RFC 6520 sec. 4 */

pl = p;

The first fix is to check against 0-bit length heartbeats and the second fix is that that request is actually as long as it says. These fixes were introduced in 1.0.1g

If such fix is not possible then developers can also recompile OpenSSL with the handshake removed from the code by compile time option

-DOPENSSL_NO_HEARTBEATS

The implementation of perfect forward secrecy protects encrypted data from several potential attacks by using a per session random keys. But it is unfortunately very rare

Detection of Heartbleed

Manual detection of Heartbleed is near to impossible since it leaves no trace but the websites that have been affected by Heartbleed can be checked using: SSL Scanner for SSL/TLS security vulnerabilities — Pentest-Tools.com