OpenSSL "Heartbleed" Vulnerability

You may have already seen reference to the OpenSSL 'Heartbleed' vulnerability which was published this week (http://heartbleed.com/).

If you have not yet seen this advisory, this is a very serious vulnerability in OpenSSL version 1.0.1 through 1.0.1f inclusive, and when exploited this bug allows a connecting attacker to retrieve sensitive memory contents from affected servers.

Exploitation of this vulnerability will allow an attacker to retrieve the private keys used by vulnerable servers, and consequently decrypt past and future traffic, and impersonate the service at will. Following the retrieval of the key material, the protection offered by the use of encrypted connections is nullified, and protected content (including personal data, usernames and passwords) may also be compromised.

The researchers who have identified the vulnerability are unsure whether it is currently being actively exploited, but the attack leaves no obvious trace in logs and consequently there is no way to ascertain whether systems (and key material) have been compromised. OpenSSL versions in the wild have been vulnerable to the attack since March 2012.

OpenSSL is, of course, widely used and a number of your applications may be affected. We strongly recommend that you take action to identify any OpenSSL-based services within your infrastructure that are vulnerable to this attack via their version, including web servers, VPNs, email and instant messaging systems.

All vulnerable OpenSSL installations should be upgraded immediately, or recompiled to prevent heartbeats - see https://www.openssl.org/news/secadv_20140407.txt

Following this, all key material that was exposed on vulnerable servers should be replaced - certificates should be revoked and reissued for public-facing services since these keys may already have been compromised.

Where applications have been protected by vulnerable OpenSSL versions, all existing session cookies and tokens should be considered compromised and invalidated. Passwords and other secondary encryption keys protected by vulnerable services should also be considered compromised, and users should be encouraged to change these details once certificates have been replaced.

Please contact us for further advice or assistance.