The heartache of the Heartbleed Bug – Part 2

By Maksym Schipka, Senior Vice President Engineering.

In our previous blog, we talked about what and, more crucially, when an individual would mitigate the consequences of the Heartbleed bug.

Something we haven’t covered yet is what an organization as a whole might want to do about Heartbleed – apart from the obvious upgrade of OpenSSL libraries. After all, if the organization was affected, something may have leaked.

There are several key pieces of information that could leak – from a less significant information leak of sequence numbers to session encryption keys and private keys for the signed website certificate. The worst leak, of course, is that of a private key for signed certificate.

If a cyber criminal had the private key of a signed certificate they would not only be able to decrypt any conversation between a client and a website (as long as they could detect relevant traffic to the site), but also set up their own websites perfectly resembling bona fide company websites with a green padlock in the address bar of any browser, luring users into thinking that a particular website is legitimate. This in turn can lead to a critical information leak of massive proportions that would of course be detrimental to a company and its stakeholders; the passwords to your emails are considered less critical but can be equally detrimental depending on the content and the contact database.

Of course, this will trigger a whole bunch of related cybercriminal activities like phishing; phishing emails, emails pretending to be from affected organizations asking people to change their passwords, etc. Fortunately, there is a way to check whether the certificate is likely or unlikely to have been compromised: look at the certificate issue date. For example, here is the certificate issue information for the Mumsnet website (which we mentioned in our last blog):

Heartbleed bug certificate

As long as the certificate is valid and the issue date is after 07/04/2014, you are safe to change your password. If not – you should wait.

Coming back to the issue of the best sequence of actions to take to address a potentially vulnerable system, our suggestions are as follows:

  1. Check that the website is vulnerable – for hints about how to do that, look at our previous blog entry. The rest only applies if the website is vulnerable.
  2. Take the HTTPS part of the website down – you do want to protect your visitors, don’t you?
  3. Apply for a new certificate. Modern providers can turn around certificates, even Extended Validation ones, within a day or less, as long as your organization is correctly validated in the first place. If it is not – I suggest revisiting your best practices for IT Security!
  4. Request your current website certificate to be revoked through your certificate provider. This is to ensure that your customers are less likely to be lured to phishing websites.
  5. Upgrade OpenSSL – see recent online articles for advice.
  6. Replace the existing certificate with the new one – from this point onwards you know that the new certificate is not compromised.
  7. Bring website back up.
  8. Verify that the website is not vulnerable.

Following this guidance should help protect your business and fight the threats and the aftermath posed by the Heartbleed bug.