My next class:

How to talk to your kids (or manager) about "Heartbleed"

Published: 2014-04-11. Last Updated: 2014-04-11 12:15:54 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

With more mass-media attention to the heartbleed bug, we are getting more questions from "normal users" about the heartbleed bug.

The "Heartbleed" bug is not affecting end users using Windows. It does not affect standard Windows browsers (Internet Explorer, Firefox, Chrome). It may affect some selected third party software, but most likely, you do not need to patch anything. The only widely used consumer platform vulnerable is Android 4.1.1, but there isn't much you can do about it but wait for a patch for your phone.

However, it is possible that a web site you used is or was affected by "Heartbleed". The result may be that the password you are using on the site was captured by someone attacking this site. So you may need to change the password that you used on the site.

How do I know if a site is/was vulnerable?

Your best bet is https://lastpass.com/heartbleed/ . They will show you if a site is vulnerable right now, or may have been vulnerable in the past. Tehre is a chance that the site received a new certificate that still uses the old issue date, which can lead to sites being identified as "not fixed". 

Should I change my password?

If you think the site was vulnerable, and is no longer vulnerable, then you should change your password. If in doubt, change your password. Changing your password while the site is still vulnerable probably doesn't hurt, but the new password may leak again, so the change may not help.

Should I avoid sites that are still vulnerable?

Yes

I received an e-mail from a site I use asking me to change my password. Should I do so?

First of all: Don't click on any links in this email. Then go to the website and change your password (even if the e-mail was a fake, it doesn't hurt to change your password as long as you are sure you go to the right site). Use the "lastpass" URL above to check if the site is/was vulnerable.

What else should I do?

Standard "safe computing" practices: use difficult to guess passwords, keep your system up to date, use anti-malware, be cautious with links distributed via e-mail.

And how do I explain the problem that caused all this?

XKCD has a great cartoon explaining it: http://imgs.xkcd.com/comics/heartbleed_explanation.png . The short summary: If an SSL connection is idle, heartbeat messages are used to chck if the other side is still listening. For example, the browser sends a message "if you are still alive, reply by sending the 3 letter word 'dog'", and the server replies with "dog". To trigger the bug, the client would send "reply with the 500 letter word 'cow'". Since "cow" only got 3 letters, the server will make up the missing 497 bytes with data from memory, and this data may contain other things the server was working on, like users passwords or private encryption keys.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
6 comment(s)
My next class:

Comments

"The "Heartbleed" bug is not affecting end users using Windows."

Well that's just plain wrong. Who are you to say that an application that is installed on Windows does not provide a vulnerable version of OpenSSL?

Anonymous

Apr 11th 2014
1 decade ago

There are very few applications that do. These applications still need to be patched, but are unlikely to affect your average windows user. Also, client applications are a lot harder to exploit in this case as they need to connect to a malicious server.

Anonymous

Apr 11th 2014
1 decade ago

I wasn't necessarily talking about client application. Somebody might choose to run nginx on Windows, for example.
http://www.kb.cert.org/vuls/id/WDON-9J3GXA

Sure, unix-like systems may be more likely to be affected. But to say "The "Heartbleed" bug is not affecting end users using Windows." is just wrong.

Anonymous

Apr 11th 2014
1 decade ago

I am curious if there is any discussion about - "Vulnerability Notification".

So far, I've received one notice from one tech website to change my password, and that they claim they've patched and addressed the vulnerability.

Is this site "safe", or has the vulnerability been assessed or addressed? What about Sans.org? Is it reasonable or prudent to expect that the risk status for (Heartbleed vulnerability) is acceptable to share with me (as a partner or consumer)?

Clearly, I recognize that this is the most widespread security risk that the internet has seen in years.

I would like to see someone present a model about what is prudent notification etiquette to make consumers aware that Heeartbleed risks have been assed, and addressed.

There is no law (today) that says that notification must be done, or in what form it should occur.

I do banking with a nationwide bank (ch***.com) and I have seen 3rd party confirmation that there is no apparent risk associated with this bank site.
Reference: http://www.cnet.com/news/which-sites-have-patched-the-heartbleed-bug/
(further note: when this site says that google.com is 'patched', does this mean that all google sites are addressed, or just google.com search site? What about mail.google.com? What about all google.com sites? Not picking on google, but many organizations have multiple web sites, and one shouldn't blindly say that "all is secure", when only the front door has been secured (but not the windows or back door).

In a security risk this broad, I would think that responsible organizations (like the one tech web site) would proactively provide information that the risk has been >>Assessed<< and >>Addressed<<. Otherwise, we are all in a state of ignorance - when is it safe to go back in the water again? Not providing notice of risk assessment and resolution like telling users to ignore the PKI warnings - when the certificate doesn't match the website's URL. "Just ignore the obvious warning flags and continue to do business as if there was nothing wrong"

I think that this is an excellent opportunity to set a model for responsible public disclosure, as we haven't seen too many opportunities to see this much risks in recent years.

Anonymous

Apr 11th 2014
1 decade ago

Do the two factor authentication methods with some of the cloud providers (Facebook, Google, etc...) help avoid this vulnerability?

Anonymous

Apr 11th 2014
1 decade ago

The SSL Negotiation occurs prior to login (since the login page itself is protected by SSL), so the vulnerability is in play PRIOR to login. Using two factor authentication does protect your credentials from theft using this method, as your credentials will (in most cases) change frequently enough that any stolen credential material will be useless to an attacker.

However, there is still lots of information to steal from memory of a Heartbleed compromised server. Secret/Private keys would be one target, as would the information that is being protected on the site - banking information, email contents or whatever that protected information might be. Other targets might include administrative logins to the server, which are often not protected by 2 factor authentication, and service logins with administrative access, which are never protected by 2 factor.

Anonymous

Apr 11th 2014
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives