Sunday, 20 April 2014

Heartbleed Bug Explained


The biggest recent fuss in the field of computer science gains notoriety day by day. Online references to the bug have multiplied over time. Anyone having basic understanding of the field of computer science and programming would know that bugs in software are very common and they come and go daily. So, what is Heartbleed and what makes it unique and so notorious?

To skip all the background and technical details skip to the section Simplified explanation of the Heartbleed bug.


What is Heartbleed?
It is a serious vulnerability (a software bug) in the popular cryptographic software library OpenSSL. This bug allows a malicious user (commonly called hacker) to steal protected information over a communication channel secured by the SSL/TLS encryption, which has OpenSSL lying at its implementation.
Specifically, this bug lies in the Heartbeat extension of OpenSSL.


What is SSL/TLS?
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) are cryptographic protocols designed to provide security for communication over Internet.  SSL/TLS protocols essentially are a set of specifications that define the mechanism for a secure communication.


Where do we see SSL/TLS?
Secure communication over Internet uses the SSL/TLS protocols. Most of the confidential information over Internet is communicated using the HTTPS application protocol that utilizes SSL/TLS protocols. Nearly all websites, web servers, chat servers, network appliances where confidential and private information can be exposed use SSL/TLS; examples include Bank websites, payment gateways, email providers, social networking websites and numerous other websites.


What is OpenSSL?
OpenSSL is a cryptographic software library that provides an implementation of the SSL and TLS protocols too. It is considered the de facto library used for incorporating SSL/TLS security on a website. So, if a website uses SSL/TLS security, there are very high chances that it uses OpenSSL implementation.


If there are vulnerabilities associated with using SSL/TLS security, why use it at all?
The vulnerabilities are not associated with the SSL/TLS protocols; the vulnerabilities exist in specific implementations. It is like saying, if items from my house can be stolen; why not leave them out in the open?  :)


Okay, if the vulnerabilities exist in specific implementations; are there other implementations of the SSL/TLS protocols?
Yes, there are a host of other implementations of the SSL/TLS protocols. See A Comparison of TLS Implementations for a comparison of such implementations. That said, OpenSSL is a very popular cryptographic library that has proven to be highly reliable and efficient over time. A bug does not make it a bad choice (since the bug has already been fixed); it is natural for other implementations to have their own set of problems too.


What is the heartbeat extension?
OpenSSL introduced an extension called Heartbeat around December 2011, with its 1.0.1 build release.  The extension’s task was to help avoid reestablishing sessions so that the SSL sessions could be kept alive for longer durations.


How does the Heartbeat extension work?
Without going into the intricate details of the headers formats, we can have a simple understanding of the Heartbeat extension. 

When a session is established, the server and the client (or the two peers) establish session keys. However, after regular intervals, the client and the server need to verify each other’s identities because of a variety of security reasons (like  session hijacking). 

One approach is to establish another session. Since, establishing a session requires multiple steps, this is considered inefficient.

Another approach (the one that the heartbeat extension follows) is to setup two code words in the beginning, one for the client and one for the server. Now, after some time (called a Heartbeat), the server asks the client back for its code word (of course, encrypted by the session key). If the client replies with the correct answer, server knows that the client is authentic. If the client cannot reply, or gives an incorrect reply, the server asks for reestablishment of session (asks again for the password).

Similarly, the client verifies the server’s identity by requesting the client’s code word. If server is unable to reply correctly, the client asks for re-verification of its certificate.


Okay, then, what exactly is the Heartbleed bug? 
As we already saw, an exchange of secret code words is performed during a persisting session to verify the identity of two communicating peers.

However, due to the Heartbleed bug, the client not only has access to the session key but also an arbitrary chunk of memory on the server side (similarly server has access to client’s memory).

The client, while verifying session, send a request to the server to return back the client's secret code word that was established earlier. In the request, client also sends the size of the data it expects the server to return. Even if the secret code was a few bytes long, the client can always request a bigger chunk of memory (an upper limit of 64 KB in one heartbeat). The server fulfills the request giving that amount of memory data back to the client (starting from the key’s location in the memory). 

So, if a client is a malicious client, it can keep sending heartbeat requests to the server potentially accessing up to 64 KB of arbitrary memory every time. That portion of memory can contain highly confidential data, including the server’s private key (access to which gives unrestricted access to the server), other user’s data etc.


Can you skip the technical details and explain in simple terms?
Okay, let’s skip all the encryption stuff. Let us imagine a scenario where you visit a bank. The receptionist asks you for your secret key (the password) to enter the bank. You also ask the receptionist for her identification. Once, you are satisfied with her credentials, you tell her the password. She verifies the password and lets you access the inside of the bank.

However, you two also setup code words for further communication. You tell the receptionist your code word and the receptionist tells you her code word. Receptionist passes these code words to all the bank’s employees, so that anyone who knows them is an employee and anyone who doesn’t is not.

Now, you are sitting in the waiting room waiting to be assisted. Now, an employee comes to assist you. However, instead of asking your password again (having to verify it from the system), he simply asks for the bank’s code word. You ask him your code word first. He tells you your code word and establishes that he is an authentic employee of the bank.

However, the employee is infected by the deadly heartbleed bug. So, while asking your code word, you tell him how many words you are expecting.  He tells you the correct code word but also tells other visitors' code words, and the bank’s code words for other visitors too, depending on the number of words you said you were expecting.

This knowledge gives you unnecessary access to private information related to other visitors. You can even impersonate as one of them.

To throw in a little technicality, the situation with OpenSSL is not as bad as the bank’s, because code words are not stored as plain texts. They are encrypted using session keys. So, just to decipher the code word, or any part of memory that was leaked, a hacker would first have to hijack a session (basically know who to attack).


Bugs in software come and go, what makes Heartbleed so unique?
The severity and ease of exploitation of the bug makes it so notorious.


The bug is very easy to exploit, does it leave the Internet insecure to all hackers?
No, it doesn’t.  The reason is, a hacker has access to arbitrary chunk of memory but he doesn’t know what part of memory (or what information) he is getting. Essentially, all he might be getting could be garbage or could be the bank account’s password of a user. It takes a mediocre hacker to exploit the bug but someone very good to get important information out of the leaked data.


How do I know that I was attacked?
You don’t. The exploitation of the bug leaves no traces, so there is no way to know if someone has already accessed your confidential information. However, if something bad hasn’t happened yet, there are pretty good chances that you weren't attacked.


How do I ensure that Heartbleed no longer affects me?
The OpenSSL developer community promptly fixed the bug, and fixes have been pushed by most operating systems. All you have to do is update your OpenSSL with the latest set of updates. After that, ask your users to change their passwords to protect from any future information theft due to an earlier password leak.



For background information on the Heartbleed bug, visit the Wikipedia article on Heartbleed.

Most of the explanations in the post are oversimplifications intended to be understandable by most readers. Please feel free to report any mistakes and give your invaluable suggestions. 

No comments:

Post a Comment