The Heartbleed Bug: Learn How It Operates

By Zulfikar Ramzan, CTO, Elastica

The entire internet security community was up in arms on Monday as a devastating new bug, Heartbleed was discovered in OpenSSL, the most widely deployed cryptographic function on the web. Google’s security team discovered the malicious bug. Since then OpenSSL has released a patch for it and issued a security advisory.

So how does Heartbleed operate? Elastica’s CTO Dr Zulfikar Ramzan explains. Click here to watch a video on Heartbleed.

Heartbleed takes advantage of a subtle, yet highly critical programming mistake in OpenSSL versions 1.01 and 1.02 beta. Systems running these vulnerable versions of OpenSSL can be easily attacked and your confidential data can be accessed.

What is Heartbeat?

Heartbeat is an extension to the TLS protocol. It allows you to keep a TLS session up and running even though no real data has gone through it in a while. It does so by sending a simple message called a Heartbeat request. This request basically helps keep a session alive between a client and a server even if there is no real activity. The Heartbeat request is sent by one computer to another with some request data that includes a payload and the size of that payload. The computer responding to a Heartbeat request will contain the same payload information.

How the Attacker Can Steal Confidential Data

The attacker will craft a special Heartbeat request with a little bit of data and information about how much data is in the request. The attacker can craft this request in a very malicious fashion. The attacker could send a payload that is very short, say just 1 byte. But instead of saying it’s just 1 byte, the attacker will lie and say it has 65,536 bytes. The code that handles the Heartbeat extension within the OpenSSL library will copy this payload that the attacker provided into its memory. As part of the response it will copy the data back out from its memory and send back a Heartbeat response to the attacker.

However, rather than checking the actual size of the payload the Heartbeat code just uses the value specified in the request. And this is a mistake. Instead of verifying if the actual size is consistent with what the requester put in, OpenSSL blindly uses the value that was included in the request. But this value could be bogus. It could be completely wrong. So what happens in this case? OpenSSL locates the starting location where it stored the payload in its memory and then copies the next 65,536 bytes as part of the response. The first byte is the actual payload that the attacker specified in his request. The remaining 65,535 bytes are the bytes that were stored in the memory of OpenSSL. And these bytes are returned to the attacker. Now suddenly the attacker sees an additional 65,535 bytes that were stored in the memory of OpenSSL, which should not have been sent to him.

What Makes the Attack Extra Potent?

Keep in mind that OpenSSL is meant to provide security for sensitive data. So the attacker has access to confidential data, passwords, or even the keys that SSL uses to encrypt and decrypt data going back and forth to you. And if an attacker has these keys he can not only decipher any further traffic, but also potentially read any past traffic that he may have recorded.

What makes this attack particularly potent is that it can be done without leaving a trace and it can be done multiple times to get different sets of data from OpenSSL’s memory. It is entirely possible that someone may have implemented this attack all along, but we just didn’t know about it!