You will no doubt have heard about the Heartbleed bug and here I’ll give you a quick idea of what it is and any action you need to take. For full details you can visit the Heartbleed website.
So what is it?
Heartbleed affects secure websites and other secure communication channels but for simplicity I’ll describe what happens on a website. Normally, you visit a website via HTTP (hypertext transfer protocol) and the traffic is not encrypted so anyone that interrupts that communication can see the data transferred. Websites that require a login or those that use forms that may request sensitive information (credit card details, personal information, etc…) tend to encrypt the messages that you send using HTTPS (a secure version of HTTP). You may be thinking why doesn’t every site use HTTPS for everything and the reason is that it is slower (it needs to encrypt and decrypt at both ends).
Websites are hosted on a web server and for that web server to encrypt the traffic it will use some software. Quite a lot of websites use the Apache web server and the most common encryption software in use is OpenSSL.
In 2012 a heartbeat function was added to OpenSSL but this contained a bug (hence the name Heartbleed). Any server using OpenSSL that upgraded to the new version 1.0.1 and did not explicitly switch off the heartbeat function was vulnerable. The vulnerability was discovered only recently and a new version of OpenSSL (1.0.1g) was released on 7th April 2014. Of course until a fix was available it was not widely publicised but there may have been some black hat hackers (bad people) that knew about the bug and decided to exploit it.
Am I at risk?
Potentially, you are at risk if you login to a website that had the vulnerability in the past unless the actions later in this article have been performed. There will also no doubt be a huge wave of scam emails heading out around the world telling you that the site was compromised and asking you to click a link to change your password on a secure website.
Just remember that no reputable website will ever ask you to click a link to login or change your credentials or to open an attachment so never trust them. You can always visit a secure website using your own link and check the status. Most will publish details of any actions required by you and for those that don’t, ask them if they were affected. To be safe it is best to change your password on secure websites that were affected but only after they have patched the site and replaced their secure certificates.
Is my website at risk?
You should check with your site administrator but by now they will have likely patched up to the most recent version if they were vulnerable. If your site does not use HTTPS at all then nothing needs to be done as this vulnerability only affects the traffic which you believe to be securely encrypted but may not be.
Sites that do not use OpenSSL are not affected by this vulnerability. Sites that operate HTTPS and use OpenSSL but never upgraded to 1.0.1 are not affected (i.e. users of 0.9.8 or 1.0.0). If your site did use 1.0.1 at any point before 7th April 2014 then you need to ask whether it was compiled with the heartbeat switched off. If not, your site was at risk.
If your site uses HTTPS then there are some simple questions you can ask to find out if your site is affected:
- Does your website use OpenSSL?
If “no”, it doesn’t have this problem.
If “yes”, go to question 2. - Has the version of OpenSSL ever been between 1.0.1 and 1.0.1f regardless of what it currently is?
If “no”, it doesn’t have this problem.
If “yes”, go to question 3. - When your site was running any version of OpenSSL between 1.0.1 and 1.0.1f was it ever compiled without the default heartbeat switched off?
If “no”, it doesn’t have this problem.
If “yes”, your site administrator needs to take action.
So what should I do?
There are online tools available to help you detect it but going to the source is safer as servers don’t always report the correct version back to these public tools. By using publically available scanners, you may also be unwittingly providing details of a websites vulnerabilities to unscrupulous people (also don’t checked sites that you do not own or do not have permission to scan as this may be deemed illegal).
If you are a site administrator (i.e. you look after the infrastructure of the website) then keep reading but if not just ask your site administrator if this affects you and what they have done about it.
Advice for site administrators
If you are a site administrator then this is my advice; establish if your site is affected but go to the command prompt and use “apt-cache policy openssl” as “openssl version” may not return the correct version information. Some distributions of Linux package OpenSSL differently and “apt-cache policy openssl” returns the correct version as per the distribution with details of the latest version available and build dates. If using the 1.0.1 branch and you didn’t explicitly compile with the heartbeat off “-DOPENSSL_NO_HEARTBEATS”, you need at least the 7th April 2014 version.
Next, if the site used OpenSSL 1.0.1 and any of the updates to it before the 7th April release and had heartbeats enabled then it has been operating insecurely for at least some of the time.
Don’t be under misconception that as long as you have upgraded to the latest version of OpenSSL now that you are safe. A hacker may have known about the OpenSSL vulnerability before it became public knowledge on 7th April and may have decided to connect to sites and get the details of their secure keys (and there is no trace if they did). With those details they can view all of your supposedly secure traffic. It is extremely unlikely that having upgraded your site, it will be compromised but even this slight chance can be avoided by following the steps above.
If you have been operating an insecure site, my advice is to take the following actions:
- Upgrade to OpenSSL 1.0.1g (or the Linux distribution release equivalent to that 7th April 2014 release). Restart Apache or other web server.
- Get a replacement secure certificate by requesting that the old one be revoked and reissued. Install it.
- If the site has a secure login then change all passwords and notify your customers, or if the application supports it, have it set all passwords to require change at next login or notify your customers that their password needs to be changed. The same applies to all other forms of secure communication (i.e. SFTP).
Note for My Web Minder customers
Everything is in hand and all web servers were patched automatically, all secure certificates are in the process of being replaced and all secure site owners will be contacted about changing passwords.