Is Heartbleed the biggest security flaw in modern computing?
What is Heartbleed
Heartbleed is a security bug in OpenSSL extension that has been recently exposed. The bug was found by Neel Mehta of Google Security and the independent security research organization Codenomicon. But what is it?
Lets talk a little technical
OpenSSL is an Opensource implementation of Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLSv1); it’s used to implement the web security protocols like ‘https’. The Opensource library was written in ‘C’ programming language.
As per the official OpenSSL git repository,A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
What does it mean in plain English,
When you connect to a server using ‘https’ protocol, all the data transfer between the server and your computer will be encrypted using an SSL certificate (Key). Only the server and your computer can read the data comes and forth. Any intercepted data between the connections cannot be read without decrypting the data using the SSL keys.
Lets see how it works. For example, when you login to your web email service provider like Gmail/Yahoo, your computer will establish a secure (https) connection between your browser and the actual Gmail/Yahoo mail server and exchange the secure keys to decrypt the encrypted message on both the ends. When you’re not making any calls to the server (idle), to keep the connection alive as well as check the computer at the other end is still connected, Server/Client uses a technique called ‘Heart Beat’ signals. It will send a very tiny byte of signal to the server and expects a response back from the server to ensure it’s still alive/connected.
The funny part is that, in OpenSSL, ‘Heart Beat’ is an optional extension that’s enabled by default. That means, most of the users would actually have “Heart Beat” functioning in their servers.
This ‘Heart Beat’ signal consists of many packets of tiny data, notably two important parameters, a payload and the length of the payload. When the server receives this signal, it’ll put the payload data in its memory. Now the client will expect a response from the server to ensure it’s still connected at the other end. The server has to send the same data what it received as a payload from client to verify the authenticity. So the server will get the parameter of payload length from the ‘Heart Beat’ signal and depending upon the length it’ll get the data from memory and sends back.
Example:
The client sends a ‘heart beat’ signal with payload ‘XYZ’ and Length as ‘15Bytes’ to the server. Now the server receives the signal and stores the payload (‘XYZ’) in the memory that can be referred with the memory address.
To send the response the server will check the parameter payload length from the ‘heart beat’ signal it received from client (i.e. 15Bytes), and then It’ll get the data of 15Bytes of data stored in the memory, stating from the allocated memory address and sends back as a response to the client. Sounds simple, right? It is indeed.
Ok, but what is the problem?
If you look closely, you can spot the problem in the above process flow. The server gets the data from its memory using the ‘heart beat’ signal length parameter. In any way the server is not verifying the actual bytes of data received as payload, it blindly takes the parameter sent by the client, which can be tailored.
The Attack PoC
To exploit this security bug, the attacker can send a tailored data as the payload length instead of the actual length of payload data. Since the server is not verifying the length in any way, it’ll put the payload data in its memory and returns back the data of length specified in the payload parameter. To understand the attack flow look at the diagram below,
The client sends a ‘heart beat’ signal with a payload of very tiny data (1Byte) and specifies that its length is 65535Bytes (maximum allowed data size) in the payload length parameter. Now the server will put that tiny data into the memory and gets back the data of 65535Bytes and send it as a response to client. Which includes the
1Byte dummy data and random data of 65535Bytes which may include sensitive data such as usernames, passwords. Even worse, the SSL certificates of the server, which can be used to intercept the data transfer between the server and client.
The attacker can do this attack again and again to get random data from server memory, until he/she get the expected data.
This attack is completely untraceable, i.e. the attack will never leave any trace to identify the attacker and no trace of any malicious activity.
Sounds dangerous. How can we fix it?
The different versions of OpenSSL versions affected by this bug are,
- OpenSSL v1.0.1 through 1.0.1f (inclusive)
- OpenSSL v1.0.2-Beta1
As a fix, OpenSSL released v1.0.1g. All the users who all are using the vulnerable versions must update to the fixed version or else they can recompile the source disabling the ‘heart beat’ extension by –DOPENSS_NO_HEARTBEATS The files modified are,
- ssl/dl_both.c
- ssl/tl_lib.c
You can check the difference from the official OpenSSL git repo,
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
Test your webserver for the ‘Heartbleed’ bug,
http://filippo.io/Heartbleed/ http://possible.lv/tools/hb/
References,
http://heartbleed.com/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 https://github.com/musalbas/heartbleed-masstest>
