A bug has been disclosed in specific releases of the OpenSSL cryptography library which means that bad guys have been able, for some time (over 2 years), to silently extract data in memory from servers that run OpenSSL to encrypt data such as passwords, VPN tunnels etc. It appears that real life compromises may have been recorded in audit logs from as far back as November last year.
We’ve seen a massive surge in SSL based scanning activity over the last few days – it’s safe to assume that if you run a website that’s still vulnerable it will already be on a hacker’s list somewhere. If for any reason you’re still not sure whether your site is vulnerable or not, head over to Qualys’ SSL Labs page and run a free scan.
Whilst a lot of attention has been paid to username and password details in the press, we don’t really see this as the scariest part of this problem, unless you are personally unlucky (this is yet another reason to setup two factor authentication wherever you can). What is very worrying is that the private encryption keys of your devices will most certainly be held in memory and can most certainly be retrieved by a third party, without you knowing, with no logs whatsoever.
What this means is that, even if you patch your vulnerable devices (more about this later), but you have already been compromised (a fact you cannot possibly know), your keys will remain the same and it will still be possible for the attacker to decrypt your private traffic going forwards (unless you are running Perfect Forward Secrecy, and you would know if you were).
Appliances and systems such as load balancers, firewalls, web servers, database servers, routers, SSL VPN devices etc. use the OpenSSL library and it is imperative that you identify if any of your internet facing equipment is vulnerable by checking with the vendor as soon as you can. You can follow this up with an analysis of internal systems with a view to patching but you must absolutely prioritise Internet facing kit.
As well as patching your systems you must re-certify all Internet facing systems as soon as you can, taking the opportunity to upgrade to 2048 bit certs if you have not already done so.
Furthermore if you have IPS devices, you should make sure they have signatures for the vulnerability which are enabled specifically for unpatched systems. Enabling these signatures globally will result in numerous false positives which may drop legitimate traffic. Cisco’s signatures of this violation are delivered as disabled by default for this reason, so simply upgrading your signatures on Cisco kit will do nothing.
Something to think about with this revelation is that if an appropriately minded organisation, like, err, the NSA or GCHQ knew about this, it is without doubt that they would go on a private key exfiltration frenzy and have the capability to decrypt stored transmissions from or between your sites at will. It is probably best to assume that every secure communication that has been ‘protected’ by these vulnerable libraries may as well have been sent in the post, without an envelope. Really.
ITC can help determine if your devices are vulnerable and advise you how to remediate systems immediately, over the next 60 days, and in the long term. If you would like to speak to us about this or any other more serious (joking) security issues, please contact: [email protected] or call 020 7517 3900
