The Internet’s Heartbleed: The unseen shadow that shattered the sense of data security through Heartbeat support since 2012

There is a devastating security vulnerability that was discovered in the OpenSSL implementation of the SSL/TLS protocol. For those who are not aware, TLS is a protocol that is commonly used to safeguard transactions on the web. Sometimes TLS is referred to as SSL and vice versa. Technically SSL is a protocol that came first, TLS is kind of a successor more or less to the SSL; you can more or less think of them as being interchangeable. So for example when you see the letters HTTPS in your web browser typically you see it next to the lock icon, it means that the webpage you’re viewing has been transmitted to you is in encrypted form and in particular, which means that your data is supposed to be safeguarded from any type of eavesdropping or prying eyes that actually goes both ways. In this case, any password you type in or any confidential data you provide to that website will in theory is encrypted and be safe from somebody trying to eavesdrop on it. In particular, the letter S in the context of HTTPS means that you are transmitting web traffic or HTTP traffic through SSL encryption. Now in version 1.0.1 and also in some of the beta releases of version 1.0.2 there is a subtle but highly critical programming mistake that can lead to a possibility of an hacker learning your confidential data, and the system that is running these vulnerable versions of SSL or in particularly these vulnerable versions of OpenSSL can be attacked quite easily. Here I’ll explain both the flaw and attack in high level and shall also talk about some of its ramifications.

What makes OpenSSL vulnerable? 

OpenSSL is actually just one implementation of the TLS protocol, but it also happens to be the most widely deployed implementation, if you have used the web with any degree of frequency there is pretty much a one hundred percent chance you were interacting with an OpenSSL implementation even though you might not realize it.

In particular there is an extension to the TLS protocol known as the Heartbeat. The Heartbeat extension allows you to keep a TLS session up and running even though there is no real data gone through it in a while by simply sending a special message known as the Heartbeat request, this is useful because before this Heartbeat extension existed if there was some temporary gap or lapse in data going between a client and server for some defined period of time then the TLS session might have terminated during that time and need to be re-established with much effort. The Heartbeat extension is also useful if you want to find out whether the peer with whom you are communicating is still there, if you send a Heartbeat request to the peer you can basically keep the session alive and you also get to know if the computer to whom the request was sent is still there because it has to respond to that request and by virtue of seeing the response you can ensure that the computer is still there and the session is still alive.

How Heartbleed exploits OpenSSL:  

The Vulnerability Walkthrough

When the Heartbeat request is sent by one computer to another, the request basically contains some request data. This data includes a payload and some explicit information that specifies the size of that payload. The computer responds to a Heartbeat request will actually contain in its response the same payload information with a little bit of padding. To execute the attack, the hacker will craft a special Heartbeat request and this request will contain a little bit of data. This data is associated with the request and contains information about how much data is in the request and the size of that request.

The hacker can actually craft a malicious request and send a payload that is actually very short. Imagine that is just 1 byte in length. But instead of saying that, the hacker will lie and say that the payload is actually 65536 bytes. Now the code that handles the Heartbeat extension piece within the OpenSSL library actually will copy this payload that was provided by the hacker provided into its memory. As part of the response it will copy this data back out of the memory and sends back a Heartbeat response to the hacker.

However, rather than checking with the actual size of the payload itself, the OpenSSL Heartbeat code just uses the value specified in the request.  This is THE mistake. Instead of verifying if the actual size is consistent with the request which was put in, OpenSSL simply uses the value that was included with the request, but this value could be bogus and completely wrong. So when hacker accurately provides a 1 byte payload but says that the size is 65536 bytes, OpenSSL will locate the starting location where it stored the payload in the memory and then it copies the next 65536 bytes as part of the response. OpenSSL locates the first byte in the actual payload that the hacker specified in the request, while the remaining 65536 bytes are just stored in the memory of OpenSSL and in total these 65536 bytes are returned to the hacker that initiated the Heartbeat request as part of the response that he’s going to receive from the OpenSSL Heartbeat extension. This is when the hacker sees additional 65536 bytes that were stored in the memory of OpenSSL and these 65536 bytes are not the ones the hacker is supposed to see.

Ramifications: Possibility of total Data Security compromise since 2012

Keeping in mind that OpenSSL is meant to provide security for sensitive data in its memory that it processes. This sensitive data could include things like your confidential data, your password, even worse it could contain things like the keys that SSL was using to encrypt and decrypt data going back and forth to you. If a hacker has these keys he can not only decipher any further traffic but if he can also decrypt any encrypted traffic that was recorded it in the past. This means the hacker he is armed with the knowledge of the decryption keys.

There is another safeguard built into SSL known as Perfect Forward Secrecy (PFS) and if it is enabled (by the way it’s mostly not enabled) then you can mitigate the risk of past traffic being compromised. That said even if a hacker gets sensitive information about the current session they can get access to data that you thought was encrypted and whose confidentiality you thought was being maintained and that can potentially be extremely dangerous.

It’s also worth noting that the hacker can repeat this attack multiple times and get different sets of Bytes from memory as well. What’s alarming is the fact that the hacker can carry out this attack without leaving a trace.

Since the attack can be carried out without leaving a trace it is entirely possible that someone is doing it all along. So hopefully this write up will provide you with insights regarding both the severity and also the high-level mechanics of the security flaw.

You can visit http://heartbleed.com/ it has a wealth of additional technical data about this flaw.