What exactly happened?
On Monday morning researchers from computer security company Codenomicon, along with Neel Mehta, a security researcher for Google, disclosed a vulnerability that would allow attackers to compromise both in-transition and locally stored encrypted communications. This includes encrypted data such as login and password information, session keys for website logins, and message text.
The vulnerability is the result of a missing bounds check in the TLS heartbeat extension for SSL, leading to an arbitrary number of 64k blocks of server memory being exposed, with one block being accessed per TLS heartbeat request. A summary of the situation can be found at http://heartbleed.com/, and a more technical breakdown of what exactly went wrong has been provided by Sean Cassidy on his blog.
Who is vulnerable?
This vulnerability is present in OpenSSL versions 1.0.1 through 1.0.1f. It was first released into the wild on March 14th, 2012 with the public release of version 1.0.1. On Monday, April 7, 2014 OpenSSL released version 1.0.1g, which patches the vulnerability, but until major websites and vendors apply this patch to their own systems, a great deal of encrypted Internet traffic is still vulnerable. Unfortunately the vulnerability leaves no log traces on compromised servers, so the true extent of the exploit is unknown at this time. Researchers have set up honeypot servers to try to estimate the volume of this exploit in the wild, but no results have been released at time of writing.
This exploit compromises the version of OpenSSL found in the current versions of the Apache and Nginx web servers, which together account for roughly 66% of all websites. Many Linux-based operating systems are vulnerable as well, including the current versions of Debian, Ubuntu, CentOS, Fedora, OpenBSD, FreeBSD, NetBSD, and OpenSUSE, which again represent a large majority of the servers underpinning the web today.
Even patching an individual site or program’s version of OpenSSL is not a complete fix, because any information transmitted may be relayed through compromised servers, allowing interception at those points. Security researchers have already demonstrated access to plaintext Yahoo usernames and passwords. Users can test individual sites to see if they are vulnerable to this exploit by entering the web address at http://filippo.io/Heartbleed/.
What can be done?
Individual users and software vendors can take steps to limit their vulnerability, but your data will not be safe unless it is encrypted before transmission and every link in the transmission chain has been secured.
Individual users can take a number of steps to limit their exposure to this vulnerability:
1. Change your passwords.
Given how long this exploit has been in the wild and how pervasive it could have been users are advised to change ALL of their passwords immediately. We realize that this is quite a task for most of us in today’s world, but it’s better than potentially exposing your accounts and data. For more tips on crafting good passwords, feel free to check out our previous blog post.
2. Clear your session keys
The exploit also allowed the interception of session keys for login. These are how your browser maintains login credentials for websites you may have navigated away from and come back to, and could allow an attacker to impersonate you on those websites. These credentials can be flushed from any browser. In Chrome, for example, you would navigate to Menu > Settings > Advanced settings > Clear browsing data, and clear the session and cookie data. You will need to clear ALL session and cookie data, as any of this could have been compromised at some point.
3. Check the websites you are using.
Before you enter credentials for the next few days, first test the websites out at http://filippo.io/Heartbleed/. Most major sites are either already patched or will be by this evening, but Yahoo at least was still vulnerable as of this morning. Better safe than sorry for the next few days.
Vendors need to follow the steps above as well, but additionally need to make sure their products and deployment systems are clean:
1. Update OpenSSL immediately.
You can check your SSL version at the command line by entering openssl version. If you are still using a vulnerable version, i.e. anything from 1.0.1 through 1.0.1f, either update to 1.0.1g or, if updating isn’t an option, recompile openssl with the compile time option -DOPENSSL_NO_HEARTBEATS
2. Request re-issue of any x.509 certificates you are using.
Any vendor that provided you with x.509 certificates can invalidate your old certs and re-issue new credentials. This is essential to do as soon as your system has been secured.
3. Scour your information pipeline.
Who processes your data? Where does it come from? Are you sending unencrypted information through someone else’s server? Know all of the points of your data pipeline and check each one. Any single hole invalidates the entire pipeline and may leave you liable for risking your customer’s data.
4. Assume your data has been compromised.
While we can plug the existing holes, there is no putting the spilt milk back in the jug. If you find that you had these vulnerabilities anywhere in your data pipeline you should act as if your data and credentials were compromised, and behave accordingly.