Imagine you’re walking out of the front door when you see the postman carrying a bundle of letters. He gives you the top letter because it has your address. You then tell him that the next five are yours too. Without looking to check the address on them, he hands you the next five letters too.
This pretty much describes the action at the core of The Heartbleed Bug. This bug was in the OpenSSL library, which is used for all kinds of encryption, but most noticeably right now: HTTPS, which approximates to “everything secure on the web”.
If you want to understand it more from an in-depth technical perspective, Troy Hunt has written an excellent and detailed article about the bug. I want to explain things to people who didn’t lose yesterday to testing and patching (or to put it another way “this is why I was looking sad and went to the pub at lunchtime”).
How big is this?
Exploiting the bug is trivial. There are already a number of exploit tools that anyone can download, point at a vulnerable server and run, and get back private data that shouldn’t be disclosed. This is not some kind of bug where “if I ask for this obscure thing in this particular way at exactly the right time in this place then I might be able to get something possibly dangerous in certain circumstances to happen”. This is a “give me some secret data please, ok thanks” bug.
The bug has been in OpenSSL since 2012. This doesn’t mean every site has been using it since then; indeed even today some sites still run older versions from before the bug was introduced. That’s a mixed blessing; newer releases will have brought bug fixes and security improvements (heartbleed aside…!)
What does this affect?
When you type a username and password into a site to log on, they should be sent over HTTPS, so that third parties can’t snoop on those details. The site will often then send you back an authentication token for your web browser to remember (as a cookie). If a site is affected by Heartbleed, your username and password, or the authentication cookie, can be retrieved by anyone remotely exploiting this bug.
I have seen this myself when testing for clients, and there have been reports of username/password leakage from big sites like Yahoo!.
That’s pretty bad. Unfortunately this probably isn’t the worst thing.
Various reports suggest that Heartbleed can be used to get a server’s private key. This is really bad. It means an attacker can:
- Impersonate the server
- Decrypt future encrypted traffic until the key is changed
- (Potentially) Decrypt old encrypted traffic
In theory, HTTPS means that if you connect to https://example.com/ then even over the most untrusted network, you know that you have a secure channel to example.com and that it is definitely example.com you’re talking to. If I have example.com’s private key, I can pretend to be them, snoop on your communications and inject my own. Replace “example.com” with the address of your bank, your webmail, etc., and the possibilities are endless.
Even more concerning is the possibility of decrypting old traffic. Roughly speaking, unless a server was using Perfect Forward Secrecy (which is apparently only about 6% of the most popular web sites), then anyone with a copy of old previously-encrypted-and-considered-secure data could decrypt it if they got hold of the server’s private key (which typically has a lifespan of the order of years). You may wonder “who would keep that data?” - think large institutions like the NSA or GCHQ. Granted, they probably also had/have decrypted access through other means, but it’s certainly a possibility.
How long has this been going on for?
The buggy code was committed on Saturday 31st December 2011 at 23:59 (make what you will of the proximity to New Year’s Eve) and became part of a stable release on the 14th March 2012. Actual usage on people’s production servers will vary, but the list of probably-affected OS versions is distressingly large.
Would anyone have noticed?
Nope. Virtually no-one would have been logging the requests - they’re small, frequent, and rarely contain anything of interest.
Many attacks and compromises show up in commonly-logged events. This doesn’t. I’d guesstimate that no-one has any real idea if and when they were exploited and what was leaked.
What can I do?
If you’re running potentially affected systems, Thomas Fuchs has a “Heartbleed exploit tl;dr” which pretty much nails it.
Otherwise, there’s not an awful lot you can do. Hopefully someone will write a browser extension that will tell users if a site is vulnerable. “Change your passwords” is advice that keeps popping up: this is absolutely pointless if the server is still compromised, but once fixed, a sensible course of action.
Dr Steven Murdoch says on BBC News: “I think there is a low to medium risk that any given password has been compromised [..] It’s not the same as previous breaches where there’s been confirmed password lists posted to the internet. It’s not as urgent as that. [..] But changing your password is very easy. So it’s not a bad idea but it’s not something people have to rush out to do unless the service recommends you do so.”
I think he pretty much nails it. When there’s a compromise, the safest response is “if it could have leaked, it leaked”, BUT there’s a usability balance. You probably won’t know if a service you use was affected. Lots of tech-related companies have disclosed this nicely, but they’re very much in a minority.
Some services are going with “we found no evidence”. See the bit about logging above. If I asked you if the air in your home had elevated Nitrogen levels last week, you’d probably “find no evidence” because you’d literally have no idea because who checks that sort of thing.
Personally, I’ll probably be changing everything, because the concern outweighs the convenience. Your mileage may vary.
Related
- Bruce Schneier on Security
- Good response page by AWS
- What Heartbleed Can Teach The OSS Community About Marketing
Thanks to David Simner, Malcolm Scott and James Nicholson for proofreading.