I recently got an opportunity to present about Heartbleed at my new work place ERNW. I took some time to do a detailed study about the vulnerability.  I am quite amazed by its simplicity when compared to its huge impact. I know there are plenty of posts about Heartbleed. It is one of the super popular attack of recent times. Here is a brief summary of the key points.

Heartbleed is an implementation vulnerability on the subprotocol Heartbeat which is an extension to support “Keep-alive” functionality in TLS. This functionality aims to check if the other party involved in the communication is still available or not. This is mainly aimed at DTLS that works on top of protocols like UDP that doesn’t have any flow management unlike TCP. An attacker can receive upto 64KB of data leaked with one single heartbeat request. Also, as the heartbeat request is considered genuine, there are no traces in any of the logs. The heartbeat protocol could be advertised by both the client as well as the server. This means that the vulnerability could be used to attack either the client or the server.

What exactly is the vulnerability?

The Heartbeat extension mentioned above allows to send request with variable payload size. This means that an attacker can change the size of the payload that it needs from the server. If the size is greater than the default size, the server would end up leaking other content from the memory. There could be sensitive information within the memory which might get leaked.

Why is Heartbleed an implementation error?

Heartbleed vulnerability is found only in OpenSSL versions from OpenSSL 1.0.1 to 1.0.1f. Rest of the versions are secure. As per the RFC of TLS, a Heartbeat request could be sent only after the client as well as the server completes the handshake. Unfortunately, the vulnerable versions of OpenSSL allowed the Heartbeat request soon after the Client and Server Hello. This means, even before the encryption begins, a rogue client/server can give a malicious heartbeat request that would result in sensitive data leak.

How can we fix the issue?

Upgrade the OpenSSL version to 1.0.1g or above. In case of compromise, make sure that the certificates are revoked and new keys are issues. This is because there is a great chance that your key is leaked. Similarly, user credentials should also be changed to ensure that an attacker didn’t steal it. You could also remove the heartbeat extension as a temporary fix.

If you like to read more, please find the PDF : Heartbleed.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s