Thursday, April 10, 2014

"How to protect yourself from the 'Heartbleed' bug"

Heartbleed is a software defect in widely used security software  which enables an attacker to retrieve (potentially sensitive) information they should not be able to access from a remote service. It is not, as it has been dubbed by TV hosts and twitter trends, a “virus” but rather something cyber criminals could use to get access to information. Security personality Bruce Schneir stated that Heartbleed on a scale of 1 to 10 was an 11 (one of the first spinal tap security quotes I’ve ever seen).

It is certainly true that this vulnerability is serious but to be clear  this attack can not be used against just any system on the Internet. This is not an immediate global pandemic affecting every system, just the ones running that specific software. It is widespread, but not absolute. Estimates state hundreds of thousands of services being exposed, but it is not as some report every single service on the planet. There are also specific race conditions (timing) where an attacker had to be using the attack when your information was accessible in memory. All of this leads to a very serious case but not the “END OF THE INTERNET” some would report. All of that said, the public should certainly take note, as should service providers and businesses – this is a big deal, but we need to keep perspective and insure the right actions are taken to limit damage. Unfortunately there is some decidedly bad advice floating around. If you want to know what Heartbleed is take a look at my original post, but herein let’s talk what consumers, businesses and providers need to do now.

Consumers:

There are complex conditions as to whether your data may or may not have been retrieved, and you should assume details like passwords may have been stolen, but a blind reset of everything could actually make it more likely that you lose your details. You need to reset passwords once a provider has patched. My fellow Forbes contributor Larry Magid suggests good places to do that. One is Filippo Valsorda’s web site, one of the first to provide a check script.

That said, whilst there are tools to test if a provider has patched  they aren’t totally reliable. In some cases they flat out don’t work, such as with a couple of mobile banking applications or ‘load balanced’ web applications. Instead ask your provider to confirm they have patched BEFORE resetting your password. If you re-set prior to the patch you are just increasing the chance of handing out your username and password . They may have a public statement, or you can contact them to check.

Some “experts” have said that passwords are safe if you haven’t changed them since before the bad code was introduced (2 years ago). Security best practices aside, this is flat out wrong.If you are changing password why not take a moment to implement better password security practice and help damage limitation in the future? See my article on password best practices here.

Lastly, Attackers may soon start sending fake notifications and links pretending to offer help or magic solutions. Be extra cautious on the web, not just because of Heartbleed but also the cyber criminals tend to jump on hot topics to launch nasty code and secondary attack campaigns.

A side note for SMEs and enterprises. Some believe this flaw only impacts web sites on the Internet, but this is not correct . There are already examples of products from security vendors to customer databases being vulnerable. You should check with any of your product vendors whether they are vulnerable and whether they have a schedule to patch (if they have not already). Some of these systems could provide attackers with the ability to escalate and further attack within your network, so it is key to think beyond just external websites.

Internet providers and hosts:

You should be making a statement about when you’ve successfully patched and mitigated the issues. Proactive customer notification would be logical, but at least a banner on your site would help. Forcing customers to guess or test themselves is just negligent.

From a technical mitigation perspective, check that your IT security team do the following. If you just apply the patch you haven’t really mitigated the risk. In some cases the vulnerability may have allowed attackers access to other sensitive security information or tokens, so additional steps may be required.

Apply the patch

Generate a new certificate and a new key (failure to do this and patch means attackers may still be able to intercept and man in the middle customers private content)


  • Revoke the old certificate and key (important, many are forgetting this)
  • Restart the service (many also forgetting this leaving the old secrets or version loaded)
  • Validate you are no longer vulnerable with the numerous test scripts available.
  • Check all your servers and services, not just the most obvious candidates. Backup servers, hot stand by and others may still be vulnerable.
  • Check for any evidence of malpractice (though unlikely available) and instigate incident response procedures and customer notification as required. Perform a risk assessment too to identify any tokens or sensitive data that may have been lost which provide attackers with alternative channels.

Donate to OpenSSL and help them enhance this important code many of us trust online!
All eyes will now be turning to OpenSSL and a huge number of security professionals, researchers and potentially cyber criminals will be sifting through the code with greater interest than before. It is therefore likely we may see follow up problems in quick succession. This is not the first bug of this kind and it is unlikely to be the last . Businesses and service providers should watch closely and insure they keep such important libraries up to date to protect their customers.

Numerous network security vendors have now implemented detection routines that look for those trying to use the attack. This is helpful to identify systems you may have missed and may enable you to react quickly in the event of further problems. Check with your security vendor on this front. It would also be advisable to check with any product vendors you use internally who use web management consoles as most are entirely focusing on websites.


0 comments:

Post a Comment