A newly discovered vulnerability in OpenSSL, 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, open source 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.

The Heartbleed bug is the latest in a series of SSL/TLS vulnerabilities uncovered this year. TLS and its older predecessor SSL are both secure protocols for Internet communication and work by encrypting traffic between two computers.

In February, Apple had to patch two critical vulnerabilities affecting SSL in its software. It first issued an update for its mobile operating system iOS, which patched a flaw that enabled an attacker with a privileged network position to capture or modify data in sessions protected by SSL/TLS. Days later, a second update was issued, this time for its desktop operating system OS X, after it was discovered that the same vulnerability also affected it.

In March, a certificate vulnerability was found in security library GnuTLS, which is used in a large number of Linux versions, including Red Hat desktop and server products, and Ubuntu and Debian distributions of the operating system.

GnuTLS is an open source software implementation of SSL/TLS. The bug meant that GnuTLS failed to correctly handle some errors that could occur when verifying a security certificate. This could allow an attacker to use a specially crafted certificate to trick GnuTLS into trusting a malicious website.  The vulnerability was immediately patched by GnuTLS.

Heartbleed is by far the most serious vulnerability in SSL/TLS to be uncovered of late. The nature of the bug and the fact that affects one of the most widely used implementations of SSL/TLS means that it poses an immediate risk.

Advice for businesses:

  • This is a vulnerability of the OpenSSL library, and not a flaw with SSL/TLS nor certificates issued by Symantec.
  • Anyone using OpenSSL 1.0.1 through 1.0.1f should update to the latest fixed version of the software (1.0.1g), or recompile OpenSSL without the heartbeat extension.
  • After moving to a fixed version of OpenSSL, if you believe your web server certificates may have been compromised or stolen as a result of exploitation, contact the certificate authority for a replacement.
  • Finally, and as a best practice, businesses should also consider resetting end-user passwords that may have been visible in a compromised server memory.

Advice for consumers:

  • You should be aware that your data could have been seen by a third party if you used a vulnerable service provider.
  • Monitor any notices from the vendors you use. Once a vulnerable vendor has communicated customers that they should change their passwords, users should do so.
  • Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain.
  • Stick to reputable websites and services. They are most likely to have immediately addressed the vulnerability.
  • Monitor your bank and credit card statements to check for any unusual transactions.

UPDATE April 10, 2014:

Symantec’s SSL Tools Certificate Checker will check whether a website is vulnerable to exploitation. You can access the Certificate Checker at the following location: https://ssltools.websecurity.symantec.com/checker/



To use the Certificate Checker, click on Check your certificate installation and then enter your website URL.