On Monday, it was announced that OpenSSL, an incredibly popular encryption library (quite possibly the single most popular), contained a rather serious security bug named Heartbleed. This name refers to the TLS “heartbeat” that is abused in order to exploit the bug.
This bug basically allows anybody to obtain an arbitrary 64kb of an affected server’s memory. An attacker can do this as many times as they need to obtain more and larger secrets. Secrets like encryption keys.
While some end users can at least get a feel for how big of a problem this is, very few are aware of how it affects them, directly, and why. What exactly can an attacker do with a “secret” from a server that you use?
I’ll also explore an SSL feature designed to mitigate this sort of attack, how it helps here, how it doesn’t and which popular websites don’t use it.
Since most security minded individuals already know most of this, I’m going to write this from the end user’s perspective. A more detailed writeup on the bug is available here.
Why it’s bad
Some websites, due to their nature, need a way to scramble information during transit to and from your computer. SSL is that way. SSL uses a public/private keypair to encrypt the information. This means that the server gives your computer the public key. When the public key is used on information, it’s scrambled, and only the private key can be used to unscramble it. The private key is stored on the server, of course. Since the private key is needed to unscramble data that’s passed between the server and users, it’s definitely a prize for attackers.
While the server is actively communicating with a client, the private key is copied into its memory. The Heartbleed bug allows an attack to read information directly from the memory. Thus, the Heartbleed bug allows an attacker to obtain (among other things) the private key. Once an attacker has that private key, they can pretend to be the server, so that you connect to a fake version of the website. If that attacker has been watching all the traffic to and from the server, and has been recording it (think NSA), it doesn’t matter if it was scrambled, because now they have the key to unlock it.
Why it’s bad for you
Let’s say you went to an online store, picked out some items, and checked out. When you entered your credit card information, you were told that the connection was secured, and couldn’t be seen by anybody. But, somebody between you and the website was watching and logging everything that passed between you and the site. Until Monday, he had scrambled information that was totally useless.
Now, if the eavesdropper just exploits the Heartbleed bug, he can get the key needed to unscramble your credit card information. It’s important to point out that there are no time limits here. Somebody could have captured a transaction 7 years ago, and if they were patient, they could have waited until now to make their move.
It’s not just credit card details. Google uses SSL to keep your searches private. Banks use it to keep your username and password secret, and to make sure that only you see your banking information. Social networks also use SSL to help keep accounts secure. Anywhere you see the padlock icon in your browser, SSL is at work, and this can happen to any of these websites.
For those worried about the NSA, this sort of flaw is why simply encrypting everything isn’t a panacea. They still captured the encrypted traffic, and they’ve been waiting patiently until they could obtain private keys to decrypt what they’ve captured. With Heartbleed, that’s not just a theoretical possibility, it’s reality. It’s a fairly safe bet that they’ve been scrambling to obtain as many private keys as possible before servers start patching their OpenSSL installations. It’s also entirely possible that the NSA has known about this bug for some time, and has been exploiting it ever since. It’s important to point out that exploitation of Heartbleed causes no abnormal activity, and doesn’t appear on any server logs.
How it could have been mitigated
The private key is a pretty big prize because it can unscramble anything that its matching public key has been used to secure. When you connect to an SSL server, there are a couple of different “modes” that can be used to scramble the data. Some of these modes demonstrate a property called Perfect Forward Secrecy. When PFS is used, the public/private keypair is only used for the two computers to “handshake” and “negotiate” a scrambling key that is only used for that session. Because of how this negotiation happens, nobody watching the exchange, even if they unscramble it, can see what the key is. The end result is that obtaining the private key doesn’t net you very much else, except the ability to impersonate the server.
If PFS makes this exchange more secure, then why isn’t everyone using it? Yes, PFS is pretty much a switch to flip, but it takes more work to perform the exchange this way. It takes about 15% more work by the server. For very large websites, this 15% on a very large number of connections is too much, so it’s just easier to keep it turned off.
Websites that use PFS just need to revoke and replace their private keys as soon as possible. Websites that don’t have a much bigger problem. You have a problem too, if you use any of these sites.
Who didn’t use it
I used Qualys SSL Labs to test a sampling of some big sites that offer SSL. SSL Labs gives servers a letter grade based on how well they’re following the “rules” of using SSL, and how well they support various optional features.
This is a short list of sites that don’t use PFS. If you have an account on any of these websites, you should change your password right away. Please note that this list is not exhaustive, and some sites that didn’t use PFS before may have literally just started to use it in the past few days.
Please Note: This list was compiled on 8 April 2014 and is probably VERY out of date. Use SSL Labs to determine PFS support for yourself!
Bank of America
Sony Entertainment Network
Amazon Web Services
Healthcare.gov got a pretty bad score!
Social Security Administration
* – Steam isn’t just leaking its private key, it’s also leaking user logins. You shouldn’t log into Steam until they fix their OpenSSL install.
That’s just a VERY small list, but it should give you a taste of how big a problem this can be. Most of these sites have patched the Heartbleed bug. Yahoo has not. Sites that don’t use perfect forward secrecy risk leaking all past transactions if their private key is exposed. Heartbleed is just one way to expose a private key.
You can use SSL Labs to check any SSL sites that you visit. Use the comment section to let me know about any big ones that are still vulnerable to Heartbleed. SSL Labs gives any vulnerable servers an “F” grade.
Update: Who is STILL vulnerable
Mustafa Al-Bassam on Twitter ran a mass test against the top 10,000 websites. He tweeted a list of these websites that are still vulnerable to the Heartbleed bug. Changing your passwords on these sites can’t hurt, but it won’t help much unless they’ve turned on perfect forward secrecy or until they rotate their keys and patch the flaw.
What you should do now
It’s best to be safe. You should change your passwords on any service that means anything to you. Use a service like LastPass to make it easy to have a unique, strong password for every site. Remember, if you use the same, or similar password everywhere, only one site has to be exploited.
If you really want to help the cause, find places that you do business with that don’t use PFS, and let them know that you’re worried about the security of your information.
Right now, you should immediately change passwords on websites that are bigger targets, like banks, email, and social media. Seriously, it’s a great time to pick up LastPass.
It also helps to turn on 2-Factor Authentication (like Google Authenticator) on all services that support it. 2-Factor Authentication helps keep people out of your accounts, even if they have the password.