The Team has updated its SSL Good Practice Guide to incorporate the recent Heartbleed attack.
In case you’ve been out of the loop, here’s a brief summary of the vulnerability:
What is it?
Heartbleed (AKA CVE-2014-0160) is an implementation flaw in TLS heartbeats for OpenSSL versions 1.0.1 through to 1.0.1f. It exposes an unpredictably addressed 64KB chunk of server process memory for each malformed heartbeat received. By performing multiple heartbeats, you can recover almost all of the server process’ memory. Basically, the heartbeat acts as an echo request, with the payload size and payload contents determined by the requester. Typically these are filled with a few bytes of data. However by putting in a payload of say, 1KB with a payload size of up to 64KB, the server will return 63KB of its own memory due to a lack of bounds checking.
What does it expose?
Heartbleed can expose anything stored in the server process’ memory, which may contain but is not limited to:
- Session tokens
- Form submissions
- Email addresses
- Usernames
- Passwords
- Private keys
Once the server’s private key is exposed, then all future traffic encrypted by this key can be intercepted and manipulated by anyone holding the key.
Who/What is affected?
Any application using OpenSSL/libssl version 1.0.1 through to version 1.0.1.f. This means both server and client are susceptible to this attack. The scope of this extends beyond just HTTPS- any service using TLS can be affected. This bug has existed in OpenSSL’s code for two years, and at this time there is evidence to suggest that this weakness has been exploited as far back as November 2013.
What should we do?
The remediation for this vulnerability is fairly straightforward, as shown below:
- Update OpenSSL to version 1.0.1g, or recompile with
-DOPENSSL_NO_HEARTBEATS
- Revoke the certificates for any services which have ever been vulnerable. This is important, otherwise the potentially compromised certificates and keys will continue to work
- Get new certificates
If you have reason to suspect that your service may have been attacked then it would be prudent to suggest that all users change their passwords, as they may have been compromised.