What Heartbleed means to you

News of the Heartbleed vulnerability affecting most e-commerce sites around the world has left users confused as to what it means and how they can go about protecting themselves. JOHN MILLER explains how the bug works and offers businesses and users advice keeping their data secure.

Heartbleed is a vulnerability that can be found in certain websites and has been making headlines since its public disclosure on Monday 7 April 2014. The technical term is the “OpenSSL CVE-2014-0160 vulnerability” and it affects any website that uses secure sockets layer (SSL) encryption. SSL is what allows Internet users to securely send sensitive information like passwords and credit card information, and is a cornerstone of modern e-commerce. It is estimated that OpenSSL (an open source version of SSL) is used on 60% of Internet-facing services. While not all of these services will be vulnerable, the effects of this bug are widespread.

The fallout from this serious vulnerability is that could affect a major portion of SSL encrypted websites and it is likely to have a long tail and continue to make news in the weeks and months to come. Although the bug was only announced recently, it has been present in versions of OpenSSL that have been released since 14 March 2012, giving savvy attackers ample opportunity to steal certificates or other sensitive information. Web servers are not the only possible target for an attack: any program using an affected version of this particular OpenSSL and that is exposed to the Internet is vulnerable. Even for everyday users who are not directly open to an attack, Heartbleed will have long lasting effects.

The vulnerability lies within a relatively new feature of OpenSSL, one of the most popular open source projects. OpenSSL is responsible for providing Secure Socket Layer (SSL) and Transmission Layer Security (TLS) encryption functionality (the ‘S’ in ‘HTTPS’). Heartbleed was discovered in the ‘heartbeat’ function of TLS, which allows long-lasting connections to remain open without the need to reestablish the encryption channel.

In a normal heartbeat, one side will send a short request and the other end relays the message back. Unfortunately, a bug allows an attacker to confuse the receiver about how long the original message was and in turn, the receiver responds with not just the original message but up to 64k of additional content straight from the memory of the affected process. The attacker can repeatedly perform these malicious heartbeats to extract valuable information from the service on the other end.

So what can an attacker get in 64k chunks of data? While they can’t choose what they’ll find, at least not directly, usernames and password, payment card details, cookies – any information submitted by other users of the service – may be exposed. This information could be used directly (in the case of credit card numbers) or in a secondary attack after gaining access to accounts. The holy grail, though, are the encryption keys and certificates used by the server to authenticate itself. If an attacker is able to gain access to a server’s SSL private key, he can decrypt user traffic and impersonate the server nearly undetectably.

In the two years since this flaw was introduced in OpenSSL it is very possible that sophisticated attackers have identified the flaw and widely exploited it. Since the requests generated to perform the attack don’t look particularly malicious, and no one knew what to look for until just recently, it is highly unlikely to find evidence of exploitation simply by reviewing logs. It is going to be very difficult, perhaps impossible, for an organization to know if their SSL certificate is compromised until an attacker is caught performing a Man-in-the-Middle attack (MitM) with it. Users, through no fault of their own, are now exposed to nearly impossible to detect MitM attempts using these stolen certificates. Every server that is or was vulnerable to the Heartbleed attack is potentially compromised: certificate owners must act to protect their users and their reputations.

Users should check with their websites that contain sensitive information such as their banking and email providers and ask them if they were affected, and if so, how they have patched the vulnerability. Once the provider has confirmed their service is fixed, users should also change their passwords.

Businesses that host their own affected SSL services should strongly consider revoking their current certificates, as compromise could lead to abuse of their users and damage to their reputation. SSL certificate owners will need to work with their Certificate Authority (CA) to reissue their certificates. Trustwave offers businesses that use its products and services free reissue for the life of their certificates.

Self-signed certificates or certificates that are signed by the same entity whos identity it certifies, cannot be revoked, leaving those certificates particularly vulnerable. Self-signed certificates normally generate warnings unless a user has specifically approved it for long-term use. These certificates should also be changed and removed from users’ computers.

Web servers are not the only application for SSL: it is used to protect a great number of day-to-day communication methods. The exposure footprint and potential for abuse varies based on how SSL is used. Any application using the affected versions of OpenSSL should be reviewed for their abuse potential and appropriate remediation actions taken.

* John Miller is Security Research Manager at Trustwave.

* Follow Gadget on Twitter on @GadgetZA