Heartbleed: Don’t change your passwords (yet)!
For the two people that have not heard of the OpenSSL Heartbleed-Bug yet, let me start with a short explanation (taken from Heartbleed Bug):
“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”
So, is that a serious issue? Hell yeah! To quote Bruce Schneier: ““Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.“
You will see lots of people recommending you change your passwords on all https:// sites. While that is generally something that you want to do now and then (in my case that would probably require me to take a week off…) _right now_ is probably not the time (yet).
Let me explain:
- If one of the sites you have an account on is affected by the issue, data from the site may have leaked, including session data, cookies or your password (although in the individual case that is highly unlikely). Also, depending on how their landscape has been set up, their SSL keys may have leaked.
- This means that it _might_ be the case that an attacker has the SSL keys and can use it to de-crypt the communication and sniff your new password, too. In order to fix that the site has to request & install a new SSL server certificate _and_ declare the old one invalid by revoking it.
- Unfortunately your browser will ignore that revocation by default. Which is why you should check the settings as described in this blog: http://www.macobserver.com/tmo/article/dealing-with-heartbleed-what-you-need-to-know/P5
- The last step is to wait for the site operator to either notify you or check on the web site that they have done the first two things (patched OpenSSL & renewed SSL certificates) – only then the site can be considered secure again!
While you’re at it, it’s probably also a good idea to renew any oAuth authorizations you may have given on thoise sites (like, allowing your blog to automatically post to Twitter).
This is going to be a loooong painful process for everyone. But there’s no point running in a blind panic now. There’s a lesson in there for everyone, I guess.
Edited on 2014-04-11 to address some of the comments:
There are two main messages I want to get across:
- If you’re changing your password before the site is fixed it won’t hurt. HOWEVER, you will not be safe until it _has_ been fixed, and you will have to change it again then.
- Just as important: STOP RE-USING PASSWORDS ON OTHER SITES! 😎
Other recommended blogs to read while you’re waiting:
Actually, many of the large site operators (think Bank of America, Chase, Facebook, etc) are not -- at this time -- proactively telling their millions of users whether or not it's yet safe to change passwords. Many -- perhaps most -- of them have already patched their systems, though it's unclear if they've also swapped out their certificates, but probably they have.
So, is it really too early to change passwords? Probably not. There's a decent list, compiled yesterday here of which sites were either unaffected by the bug, which sites were affected but have taken steps to fix it and are now recommending password changes, and which sites for whom it remains unclear. It's a short list, of course, but many of the big players are on it.
Besides, if you're concerned about it, you can always change your password now, and change it again in a week. If they already had your old password (because you logged in since April 7, or because the crooks knew about this before it was public), then at least you're making them work for it to again have your new password.
The big one -- for us -- who isn't mentioning whether their software is safe is... SAP. Is the Service Marketplace safe? Is SCN safe? Are my own ABAP and J2EE systems unaffected?
Thanks, Frank, for opening up a conversation on this. On the question of whether our own SAP systems are affected, I started a discussion thread yesterday. Several people I consider experts have weighed in, but no one yet seems to be absolutely, positively certain.
That's kinda my point: if you have sites indicating they have taken all the steps (including renewing the certificate!) by all means go and change your password.
I reserve a bit of scepticism, though, as changing and revoking the certificate is a process that may actually take some time; some companies might just be reluctant because a) there's money involved b) "nobody will notice" or c) a risk assessment about the likelihood of the keys having been exposed.
Overall, it's another blow to the trust we put in online systems. A real bummer.
I'd give it a 20 on a scale from 1 to 10, for OpenSSL users.
On the other hand, looks like only versions of OpenSSL are affected (v. >=1.0.1). 0.9.8 and 1.0.0 are not affected, and as hard as it sounds, but there are sites that run an old, but supported version (may the lazy admin be praised). Just because a site runs SSL also does not mean that they are affected, as a lot of sites are not using OpenSSL.
When now people are changing their Yahoo password because they fear their password was stolen: I doubt that kind of zero day exploit was used by spammers. This is just too valuable to be used for SPAM (that will end in your SPAM folder anyway). An SSL exploit that does not leave any traces? How much is that worth?
What I can think of is capturing the accounts and than sell it back to the victim. But even that is pretty dangerous. If this exploit was used, than for other things.
Problem is when this enters Metasploit and service providers do not update their OpenSSL libraries.
Allready has entered metasploit...
A general comment. In case you missed it, the list of vulnerable software includes now also hardware devices such as routers from Cisco, F5, Juniper, etc.
And VPN, SMTP + TLS, Vmware ESX infrastructures and I guess plenty of other products you would not expect from home-automation to your mother in law and her tesla 😉
Nice blog, but one thing I would have added would be advocating the use of a password manager like LastPass or KeePass.
The former now has a built in check to see if the websites you have passwords for are still vulnerable or not. Both encrypt your passwords locally, so are never shared with them; and it's much easier than trying to remember strong passwords that are 32 characters in length, made up of upper and lower case letters, numbers, and special characters. They also work with SAP Portal and the Windows GUI!
There's also a Chrome extension that can check if the website you are using hasn't patched the Heartbleed bug, you can get it here:
that's in the blogs I linked to at the bottom - password managers are not a specific remedy for Heartbleed, but a good idea nevertheless 😉
Yes, I'm a fan of these tools as well.
I'm no security expert and I never played one on TV, but people also need to be aware that the bad guys will use this opportunity to send you emails purporting to be from various sites and encouraging to disclose usernames and passwords.
Just to be grumpy here, but wasn't using OpenSource Libraries which are supposed be "good" and properitary stuff from vendors = "bad", keep us out of this mess. It seems like everyone using this library failed to actually review the source code in the first place before using to make sure that the Open product really did everything it said it could securely.
My other question is who among the open source folks is responsible for this mess. Oh wait that's right you give up the right to sue for defects and use the code at your own risk. Once again I really think many people failed to use common sense and just followed the "cool thing to do" and now the general public is suffering from laziness/cheapness of companies.
I hope that SAP will strongly consider to stop using open source blindly along with following open source practices blindly, without first really really examing what they are going to inflict on their customer base. I feel that many of the current open source tools being forced upon customers are more about being "open source cool" instead.
Keep in mind I'm not against using open source products or the concept, it just goes to show that if you use anything productively you better examine the code yourself from the open source before making use of it. OpenSource was supposed to make sure that this type of issue should have never happened. Instead we have become too lazy to review the work of others before adopting it and instead are being subject to the fallacy of the mob mentality.
I agree completely with some of your comments, and call BS on the rest. I agree, it seems reckless to install free software that you get access to the code for, without at least checking and or testing the code.
Open Source was not meant to be somebody writing code and the rest of the world leaching off them. What happens (and heartbleed is a good example of it) is something similar to the tragedy of the commons; it appears that something like two thirds of all sites on the internet are using openSSL. Despite this the eleven active developers receive very little financial support; In a typical year the OpenSSL project receives about US$2000 in donations.
As for code quality, we know (from the Apple SSL case) that closed source software is no more secure or bug free. We know from the RSA case that, depending on who is paying, lower security may be a feature not a bug. To return to my original point, it is the endusers responsibility; would you install a closed source product that you suspected was insecure ? Well, Open Source gives you the opportunity to find out, but someone still has to actually look.
EDIT: for a simple yet accurate explanation of how #heartbleed works, go to xkcd: Heartbleed Explanation
I'm not blaming the open source guys who built the code if that's what you are trying to say. I'm blaming the fact that everyone who used such code didn't due their due dilligence and didn't verify/look at what they were using in detail for production systems for a critical piece. That's my point. If you don't have someone else to sue/support your productive code then you better make sure that you validate to the best of your ability yourself.
The problem seems like you had way too many companies with IT budgets much greater than what is being spent by this project and failed to spend enough money on validating a fundamental component of their infrastructure. That's the biggest failure and once again it's not the developers creating the solutions, but rather those consuming.
Yes the close-source solution probably has more danger and we can't see it. Nor do I want everything to be closed-source in the first place(I first used linux almost 20 years ago). That's the frustating part of this situation is that proper investment in open source would have prevented this in the first place. It's the concept that because software is free that it requires zero dollars investment in taking care of is the mentality that we need to break.
With OpenSSL being, well, open, it allowed some experts to actually find the bug (let's just not assume it was placed there by, let's say, NSA). While right now a companies that use IIS with MSFT technology can say that they are not affected, please bear in mind that the heartbleed bug was born while RFC 6520 being implemented.
Just because you are not aware of a bug in a proprietary closed source software, does not mean that it is not there. It is just harder to discover. Which means that a bug like heartbleed can be there, and peole/organization with the right methods can find it out (attack MSFT engineers, copy source code)
What is of interest is: using code quality systems could have helped? It looks the bug is caused by a "simple" memory copy without range check. Something a person may overlook, but a software looking for this kind of possible bug? Someone knows if OpenSSL uses a QA Software for code analysis?
Many main companies, such as Google, Facebook, Twitter, Apple, LinkedIn, etc, offer double authentication.
I would suggest to activate double authentication wherever it is available, it makes you safer even if your password is stolen...
We just need the vendors to standardize - Google, Facebook and WordPress can use TOTP with the same generator, PayPal has a (rather broken) SMS mechanism (SMS is not exactly known as a reliable service - if your token is valid for 30 seconds it would be nice if it actually arrived in that time frame...).
Some people could see session cookies when playing with hearth bleed bug. It could be argued that it is even worse then stealing private key because you still have to have control over network to use stolen key for something evil.
Not that I don't like two factor authentication but it's not a silver bullet. When it becomes more popular there will be more malware that will steal these token.