The Heartbleed security flaw (also known as CVE-2014-0160) is a very serious flaw in the openSSL library, which is library used to secure communications between computers including servers around the world. The library is used for different reasons – but some examples of openSSL usage include SSL certificates used on webservers (the padlock which indicates an encrypted connection), TLS communications between servers and to securely collect or send email using ‘secure protocols’ via SSL.
This security flaw or bug affects any server with the openSSL libraries installed, which in reality, is a massive number of servers – some estimates are that as many as 2/3rd of servers were vulnerable to this security flaw!
What exactly is the bug? For those of you who are technically minded, you can get the techi run-down over at Heartbleed.com – for us regular users, what this means is that the security layer of the internet was able to be compromised. Sounds fairly serious? Yes, it is VERY serious.
This security flaw was demonstrated to leak memory from servers known to have the broken openSSL library – ie, data in the memory of the server could be read, potentially by a malicious user, over a connection supposedly secured by openSSL encryption.
Because memory was dumped in fairly large blocks, there is a possibility that that secret keys used to encrypt the connection could have leaked, as could just about anything else in memory of the server at the time of exploit.
Do you understand the implication here? Anything in memory – including usernames + passwords could be leaked from a server with this vulnerability. ANYTHING.
What is 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 span releases of openSSL 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”.
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)
Example: enter your mailserver – mail.yourdomain.com:443 or mail.yourdomain.com:995
If your server(s) show as “vulnerable” – PLEASE STOP USING THEM – do not login, do not collect email, do not use the SSL portion of the website until it is patched. The server’s openSSL libraries need to be upgraded as quickly as possible (yesterday was not soon enough). Now that the vulnerability is public knowledge, 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 (as is the current 1.0.2 beta) – but to complicate things, CentOS released a patched 1.0.1e – and servers running 1.0.1e could be safe or 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 on the 8th of April – phone your vendor and ASK them. If they were patched after the exploit was known, we recommend that every password (including database passwords) be changed. Use new, very strong strong passwords – do not revert back to old passwords – refer to our article on most commonly used passwords in 2013.
Furthermore, every SSL certificate issued prior to patching needs to 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 and the data could have been leaked from the client end – client and servers can exposed in a memory leak.
Getting your SSL certificates re-issued means creating a new Certificate Request + Private Key – contact your SSL vendor for instructions on how to do this – and please be aware, that some vendors will possibly charge for certificate re-issues.
Server administrators and IT consultants need to take this flaw seriously – patching your flawed openSSL libraries and then simply forgetting about it is nowhere close to a guarantee of safety – re-issue your SSL certificates, and then embark on a campaign to change EVERY SINGLE username+password – and change them all NOW!!!.