July 22, 2024

How to protect yourself from Heartbleed

The Heartbleed vulnerability is one of the worst Internet security problems we have seen. I’ll be writing more about what we can learn from Heartbleed and the response to it.

For now, here is a quick checklist of what you can do to protect yourself.

If you are a regular user:

Most of the sites you use were probably vulnerable. Your password might have been leaked from any one of them. Unless you’re sure that a site was never vulnerable, you should change your password on that site. (It’s not enough that a site is invulnerable now, because your password could have leaked before the site was fixed.)

Yes, it’s a pain to change your passwords, but you were really meaning to change them at some point anyway, weren’t you? Now is a good time. (It’s also a good time to turn on two-factor authentication, on sites that offer it.)

But, before you change your password on a site, you need to make sure that that site has closed any remaining vulnerability. Look for an unequivocal statement from the site that (1) they are no longer vulnerable and (2) they have changed the private encryption key they use to protect HTTPS traffic. Once you’re sure that they have done those two things, then you should go ahead and change your password on the site. If they haven’t done those two things, then it’s best to wait until they do. Make yourself a note to come back and check in a few days.

The bad news is that some of your private information might have leaked from a vulnerable site. It will be very difficult to tell whether this happened, even for the site itself, and nearly impossible to undo a leak if it did happen.

If you run a website that supports HTTPS, and you run your own server:

  • Go to http://filippo.io/Heartbleed/ and enter the name of your site, to test whether your site is vulnerable. If you’re not vulnerable, you’re done. If you are vulnerable, carry out the following steps.
  • Upgrade your server software to a non-vulnerable version. I can’t give you general advice on how to do this because it depends on which software you are running. Once you have done the upgrade, go back to http://filippo.io/Heartbleed/ and verify that you are no longer vulnerable.
  • After upgrading your software, generate a new SSL/TLS key and get a certificate for the new key. Start using the new key and certificate. (This is necessary because an attacker could have gotten your old key.)
  • Revoke the certificate you were previously using. (This is necessary because an attacker who got your old key could be using your old key and certificate to impersonate your site.)
  • Have your users change the passwords that they use to log in to your site. (This is necessary because users’ existing passwords could have been leaked. You need to get your house in order by carrying out the previous steps, before users can safely change passwords.)

If you run a website that supports HTTPS, and you use a web hosting service:
In this case, the hosting service runs the web server that powers your site.

  • Find out from the hosting service whether its server was ever vulnerable to Heartbleed attacks. If you’re confident that it was never vulnerable, then you’re good. Otherwise, carry out the following steps.
  • Wait until the hosting service has upgraded its software to a non-vulnerable version. Once they have done the upgrade, you should be able to go to http://filippo.io/Heartbleed/ and enter the address of your site, and be told that it is not vulnerable. If this isn’t true yet, ask the hosting service to fix the problem, then wait a while and repeat.
  • Once the hosting service has upgraded its software and the test site shows you as not vulnerable, generate a new SSL/TLS key and get a certificate for the new key. Start using the new key and certificate. (This is necessary because an attacker could have gotten your old key.)
  • Revoke the certificate you were previously using. (This is necessary because an attacker who got your old key could be using your old key and certificate to impersonate your site.)
  • If your site assigns passwords to users, have your users change the passwords that they use to log in to your site. (This is necessary because users’ existing passwords could have been leaked. You need to get your house in order by carrying out the previous steps, before users can safely change passwords.)

Comments

  1. I am really happy to read this blog posts which contains lots of helpful data, thanks for providing
    these kinds of data.

  2. Everything is very open with a really clear explanation
    of the issues. It was really informative. Your site is very useful.
    Thank you for sharing!

  3. Daniel Wang says

    I would be interested in seeing a follow up post about how existing certification standards like FIPS are succeding or failing to raise the quality bar for security protocols in general. I think this is the 3rd ssl/TLS related defect publicly disclosed within the last few months. It is definitely the case that the existing market forces are not doing a good job in providing robust security for the consumer space. Can we nudge the market to do better, by providing what amounts to a UL seal of approval for security critcal infrastructure? Should that cerification be an extension of things like FIPS or a new industry lead effort?

    Basically these bugs in the code are cause by a failure of the actors to be responsible. How do we fix this?

  4. Robert Scroggins says

    As an ordinary user (with an interest in security), I think Jon Bauman’s comments apply to my situation more than anything else said. This bug has been around for 2 years. I have not had my identity/passwords stolen during that time (to my knowledge–but such theft should probably have manifested by now). Reputable sites have probably acted to protect themselves by now. So I am potentially at risk from the time the bug was announced (Monday, April 7??) until sites I deal with activated protection to correct Heartbleed. In order for someone to steal information via Heartbleed, things have to go just right for the thief, so my window of damage is only a few days. Any damage done to me has already been done. So I think my best course of action is to sit tight and monitor my email and finances for a reasonable period of time (4 weeks??) and not change all of my passwords.

    Regards,

  5. Hi Ed, question: Easy enough to check if a site has patched their ssl, but is there an easy way in the browser or with the CA, to see if they’ve revoked/reissued their pk & crt?

    I reissued mine and it now shows “Valid from 4/8/2014″…shouldn’t reissued certs show a >= 4/7/2014 start date?

  6. Jon Bauman says

    It seems to me that the only very likely class of attack that changing my password protects me against is one wherein the adversary previously exploited the vulnerability to gain my password (or information that would allow them to reset my password) and will go back later to do bad things possible with access to my account. Any site worth a damn doesn’t actually store passwords anywhere (only hashes). So really, how does going and changing my password improve my security on any site who’s security isn’t already abysmal?

    If the attacker extracted personal info (DOB, SSN, etc.) through the vulnerability, that is already gone and changing my password does nothing.

    Thinking about it more, I guess if a server’s encryption keys were compromised an adversary could’ve used that to mount a MITM attack and get my password that way. Still, MITM is not easy to pull off. Are there other scenarios where a password reset helps me I’m not seeing?

  7. sattar rind says

    We have nothing to hide from heartbleed as our heart already bleeding.

  8. Ariel Feldman says

    Asking everyone on the Internet to change every password is totally crazy. It may be necessary in theory, but we as security practitioners must realize that there’s no way that that’s ever going to happen. We don’t get to say to the rest of the non-technical world: “Our bad. Now would you kindly start over because we messed up in a way that you don’t understand.”

  9. One note on risk factors. Some people who are testing servers say they have not seen servers’ private keys being leaked via Heartbleed attacks. These results should be given some weight. However, there is still a lot we don’t understand — some of which might never be well understood — about the factors that cause one chunk of memory rather than another to be leaked. [Geeky details: It has to do with the layout of dynamically allocated memory blocks in a complex multithreaded program.]

    My current view is that the risk that a server’s private key could have been leaked is still too high to ignore, given the consequences that would follow from such a leak. So the prudent course of action is for sites to switch keys and revoke their old certificates.

    I would change this advice if I saw stronger evidence that Heartbleed is definitely incapable of leaking private keys.

  10. You could add to this by suggesting whether people with HOSTED websites that use SSL certs should get their SSL certs redone??

    For example, if one has a GoDaddy or Verisign SSL certificate because your site offers online shopping or any other kind of servces like email etc., should the SSL cert be regenerated and re-installed??

    The question only applies to the certs, the server does not necessarily have OpenSSL on it.

    Thank you, Tom