Given the serious nature of this vulnerability, it is worth taking the unusual step of explaining what it is and what makes it so serious. The vulnerability can be found within certain versions of a software component called OpenSSL. This is very widely used within the industry by server vendors (typically Linux vendors), by software vendors (such as Apache), and by vendors of appliances.
(with thanks to xkcd.com)
If in doubt it is safest to assume that OpenSSL is being used because it is likely to be used in unexpected places.
How Does This Affect Me?
If you are not a server administrator, you may be wondering whether you are at risk. The short answer is that nobody knows how much of a problem this will be for you. For example, out of the top 1000 web sites around the world, 47 were known to be vulnerable as of the 8th April.
Which means that any account passwords for those 47 web sites may be compromised, or all encrypted communication may have been disclosed. The answer here is to read any announcements on the web sites about this vulnerability and take any actions they suggest – which may include changing your passwords.
It is also necessary to keep any client software updated; most news concentrates on the server side but clients are also vulnerable. However whilst they are vulnerable, nobody has demonstrated any exploits for the client side, so you aren’t actually actively being attacked.
But it may well not remain that way. So aim to apply updates to your machines – laptops, phones, tablets, etc.
Of course if you are a server administrator, there’s quite a bit of work to be done …
But What Is It?
When connecting to an SSL-enabled service such as a secure web site, an SMTP mail service, an encrypted mail service, etc., a negotiation takes place to determine what encryption should be used. This negotiation includes lots of functionality that is optional including a “heartbeat” function.
The code implementing this functionality is vulnerable, and allows an attacker to read information from the server they are attacking. Including the encryption private key.
What Are The Consequences?
If you are running a vulnerable service, and an attacker steals your SSL private key then the attacker can :-
- Decrypt any communication with your service that they manage to intercept.
- Implement a man-in-the-middle attack with perfect credibility, as they can impersonate your server with as much authenticity as your own server.
This lasts whilst you continue to use the compromised private key and is not fixed by simply fixing the vulnerability; the compromised certificate needs to be revoked and a new one used.
It is not possible to determine if a private key has been compromised or not.
How Is This Fixed?
There are several stages to dealing with this vulnerability :-
- Identifying the vulnerable servers and services. This is not a simple issue as the vulnerability will show up in unexpected areas. It’s not even as simple as identifying servers running the vulnerable software release; whilst enabled by default, the “heartbeat” functionality can be turned off.
- Update all of the vulnerable servers and services.
- Generate and distribute new certificates for all of the identified services.
- Revoke potentially compromised certificates.
It is important that new certificates are not distributed to services that still need to be updated.
Has It Been Exploited?
The short answer to that is that nobody knows. The vulnerability has been present within the OpenSSL code for more than a year, so it is possible that unknown hackers have known about this.
Indeed it is the sort of vulnerability that people like the NSA and GCHQ would be keen to make use of.
When the exploit is used, there is no way of detecting from server logs what has happened so any historical exploitation would have gone undetected. There are signs that people are actively hunting for vulnerable services – either for checking purposes (how many sites are vulnerable?) or to try exploitation.
Further Information
This blog entry will be updated as further information becomes available. In the mean time :-
- The CERT announcement of vulnerability #720951. CVE vulnerability announcement.
- The Heartbleed website.
- Very technical SAN webcast (requires log in).
- Simplified technical explanation of Heartbleed. But is perhaps simplified to the point of inaccuracy.
- Detailed, but probably the best technical explanation from a mainstream media organisation (The Register).
- JANET Certificates and advice.
- Heartbleed scanner (which may give false errors). And another one (which looks to be more reliable). And a third which gives a lot more information. However it may be illegal to scan servers you don’t own/operate.
- Tenable blog entry.
- It may be a lot harder to get the private key than initially suspected.