The Heartbleed bug (known as CVE-2014-0160) is a very serious bug in the openSSL library, which is the security library used to secure communications between computers for many different reasons – examples of openSSL usage include SSL certificates used one webservers (the padlock which indicates an encrypted connection), TLS communications between servers and email collected or sent over secured connections using ‘secure protocols’.
This particular bug affects any server with the openSSL libraries in place, which in practice, is a very large numbers of servers – some estimates are that as many as 2/3rd of servers were vulnerable to this security flaw!
So what exactly is the bug? For the technically minded, you can get the technical explanation at Heartbleed.com – for the regular user, this means the security layer of the internet was able to be compromised. Sounds serious? Yes, it is pretty serious.
This flaw has been demonstrated to leak memory from client to server and from server to client, ie, data in the memory of the server, or the client, could be read, potentially by either party, over a connection supposedly secured by openSSL encryption. This means that secret keys used to encrypt the connection could have been leaked, as could almost anything else in memory of the server at the time of exploit. Did you get that? Anything in memory – including usernames + passwords could be leaked from a server with this vulnerability. ANYTHING.
Worse perhaps than the memory leak itself, is the fact that someone exploiting this bug leaves no trace, and there is no way to know what portion of memory could have been leaked.
Why is this bug so critical? The flawed libraries used on many servers as implemented in openSSL, span releases for the last 2 years – it is difficult to put any accurate count on the number of affected servers, but as CNN put it – “The Heartbleed security flaw affects most of the internet”.
So how should you keep yourself safe from this bug?
You need to determine if your servers (or the servers you use) are currently affected – you can use this website to check your server:
Enter the server name or IP address, followed by an SSL secured port (443 for https protocol, 995 for SSL-POP and 465 for Secure SMTP)
If your server(s) comes back as vulnerable – STOP USING THEM – do not login, do not collect email, do not use the SSL portion of the website until it is patch. The server’s openSSL libraries need to be upgraded as quickly as possible. Now that the vulnerability is public, there are bound to be malicious actors who are scanning for servers with this weakness. openSSL libraries 1.0.1 up to release 1.0.1g are potentially affected by this – but to complicate things, CentOS released a patched 1.0.1e – and servers running 1.0.1e could be safe of vulnerable (if you’re the server admin you can check using the release date of the library).
Assuming that your provider’s servers are not vulnerable does not mean that they did not patch them yesterday. Find out if the servers were patched yesterday – if they were, we recommend that every password (including database passwords) be changed. Use new, strong passwords – do not revert back to old passwords.
Furthermore, every SSL certificate issued prior to patching should be re-issued as well – not just SSL certificates deployed on servers which had the vulnerability – but EVERY certificate, because the CLIENT requesting access could have had the flaw.
Getting your SSL certificates re-issued generally means creating a new Certificate Request + Private Key – contact your SSL vendor for instructions on how to do this – and be aware, that some vendors will charge for certificate re-issues.
Server admins and IT consultants need to take this flaw seriously – patching your flaw and forgetting about it are no guarantee of safety – change certificates and username+password – and change them all NOW.
Guest writer Greg Hewitt-Long runs the security IT consultancy Computer Security Solutions llc.