Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Heartbleed bug poses serious threat to unpatched servers

Dick O'Brien, Symantec | April 11, 2014
Heartbleed allows attackers to intercept secure communications and steal sensitive information such as login credentials, personal data, or even decryption keys.

A newly discovered vulnerability in one of the most commonly used implementations of the SSL and TLS cryptographic protocols presents an immediate and serious danger to any unpatched server. The bug, known as Heartbleed, allows attackers to intercept secure communications and steal sensitive information such as login credentials, personal data, or even decryption keys.

Heartbleed, or the OpenSSL TLS 'heartbeat' Extension Information Disclosure Vulnerability (CVE-2014-0160), affects a component of OpenSSL known as Heartbeat. OpenSSL is one of the most widely used implementations of the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols.

Heartbeat is an extension to the TLS protocol that allows a TLS session to be kept alive, even if no real communication has occurred for some time. The feature will verify that both computers are still connected and available for communication. It also saves the user the trouble of having to reenter their credentials to establish another secure connection if the original connection is dropped.

How does it work? Heartbeat sends a message to the OpenSSL server, which in turn relays that message back to the sender, verifying the connection. The message contains two components, a packet of data known as the payload which can be up to 64KB and information on the size of the payload.

However, the Heartbleed vulnerability in OpenSSL allows an attacker to spoof the information on the payload size. For example, they could send a payload of just one kilobyte in size, but state that it is 64KB.

How an OpenSSL server deals with this malformed Heartbeat message is key to the danger this vulnerability poses. It does not attempt to verify that the payload is the same size as stated by the message. Instead it assumes that the payload is the correct size and attempts to send it back to the computer it came from. However, since it doesn't have the full 64KB of data it will instead automatically "pad out" the payload with data stored next to it in the application's memory. If the server received a 1KB payload, it will thus send it back along with 63KB of other data stored in its memory. This could include the login credentials of a user, personal data, or even, in some cases, session and private encryption keys.

The data the application sends back is random and it is possible that the attacker may receive some incomplete or useless pieces of data. However, the nature of the vulnerability means that the attack can be performed again and again, meaning the attacker can build a bigger picture of the data stored by the application over time.

Private encryption keys may be the most difficult thing to steal using this attack. Data is stored in a sequential fashion, with new data stored in front of older data. Encryption keys will usually be stored "behind" the payload in memory, meaning they are less likely to be accessed. Content from current SSL/TLS sessions is the type of data most likely to be at risk.


1  2  Next Page 

Sign up for Computerworld eNewsletters.