Heartbleed has certainly been the security and privacy mistake/incident of April, if not of 2014. There has been a lot written about it, much good and much bad. I’ve gotten dozens of questions about it and provided an explanation in layman’s terms on the Great Day morning news show. Here are the most common questions, and associated answers, that I’ve received from several of my small- to midsized clients about Heartbleed that have involved the most confusion; let’s clear up that misunderstanding!
Is Heartbleed a virus?
No, Heartbleed is not a virus. Heartbleed is a coding error that was made in versions 1.0.1 through 1.0.1f of the Heartbeat section of OpenSSL. Other versions of OpenSSL do not have this vulnerability. To put it simply, OpenSSL is used by over 600,000 Internet-connect websites and devices to secure data that is being collected and transferred. The portion of the code is where the coding error exists is called the Heartbeat section.
What is the risk?
The Heartbleed bug generally allows anyone on the Internet to read the memory of the systems using the vulnerable versions of the OpenSSL software. The memory contains data that was recently collected by the server or device, or passed through it. Heartbleed also compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. Heartbleed allows attackers to eavesdrop communications, steal data directly from the services and users and then to impersonate services and users.
How long has this been a problem?
The vulnerability was introduced in Germany just before midnight on December 31, 2011 when Dr. Robin Seggelmann (who programmed code to enable the ‘Heartbeat’ function (basically to continuously check to see if the connection is still valid) into OpenSSL) submitted it for review. The reviewers did not catch the error and made the code publicly available March-April 2012. It was then subsequently installed by over 600,000 sites and devices.
How do I know if a site or device is using a vulnerable version of OpenSSL?
Here are some resources that can tell you if a site is vulnerable:
You can also see a list here (https://zmap.io/heartbleed/).
The critical Internet vulnerability doesn’t just affect web servers, but also many types of routers and networking hardware. Android 4.1.1 had the heartbeat feature turned on, so those devices are also vulnerable.
Wireless routers also typically use OpenSSL, so they may also have the vulnerable Heartbleed code. Here is a good article describing how to check your wireless router. It’s important that if you find any devices, sites or apps that have the vulnerability that you then report it to them.
Is it even worth the time to change passwords for sites that haven’t fixed their code yet?
Yes! Definitely for the websites you’ve used in the past couple of years where you have shared sensitive personal information. If cybercrooks have gotten your password previously, why give them time to use it while waiting for the bug to be fixed? Change them now, and again when the sites and/or devices have been fixed. It is a good idea to change passwords at least at sites that have the Heartbleed vulnerability that you’ve visited since Heartbleed became public on April.
Is it a waste of our time to fix our company’s code for our website since it has been out there so long??
It is never a waste of time to fix a security vulnerability within code, especially code that is being used to secure data. If you are using vulnerable versions of OpenSSL you need to fix it. In fact, if you choose not to fix it, you are not only being irresponsible for the security and privacy of those using your website(s) and/or device(s), but you may very well be in violation of multiple regulations and laws that require organizations to appropriately mitigate security risks.
If you have the vulnerable version of OpenSSL, here is how to monitor to see if there is an active exploit of Heartbleed on your network in the meantime while you are getting your system(s) fixed.
I was told by one of my membership sites that since they don’t store the site’s passwords on their webserver, they don’t have anything to worry about with Heartbleed; is this true?
No, this is not true. As described earlier, this vulnerability exposes data in memory. So, a website with the Heartbleed vulnerability that collects IDs, passwords, or other sensitive information, is putting that data at risk even if they are not storing it on their webserver. It is at risk while it is in memory (and basically all data collected on a webserver is in memory for some amount of time).
Have there been any breaches through the Heartbleed error?
It is impossible to know if there have been breaches prior to the announcement of the existence of Heartbleed on April 7, 2014; exploiting the vulnerability leaves no digital trail. So, there may have been many breaches since 2012 when the vulnerability was created, by cybercrooks who discovered the security hole. Or, there may have been none. We will never know a specific number for sure.
However, organizations using the Heartbleed version of OpenSSL can install a network tool to catch any cybercrooks that are using the hole to syphon data. And, some crooks have been found doing just this. For example:
- Canada’s tax-collection agency reported on April 14 that sensitive personal information of around 900 people had been stolen from its computer systems over a six-hour period by a hacker exploiting the Heartbleed vulnerability.
- The social networking site in the UK, Mumsnet, became aware of their Heartbleed hole on April 8th then applied a patch on Wednesday April 9th. However, they did not change their passwords. At least one hacker had the Mumsnet CEO’s account information, that had been obtained through the Heartbleed hole, and used it to post a vile message to the site on April 11. Many other login credentials for the site were also obtained. Mumsnet then changed all the site’s user passwords on April 12.
Note that the Mumsnet breach highlights the importance of changing passwords as soon as possible after the code has been fixed.
Bottom line for all businesses of all sizes…
If your business is using version 1.0.1 – 1.0.1f of OpenSSL, which has the Heartbleed vulnerability, you need to get it fixed with a secure version. You also need to check to see if the sites and devices you are using that involve sensitive and personal data use, or used, the Heartbleed version and then change all your passwords for them. If they’ve not fixed their code yet, ask them to as soon as possible, and then you’ll need to change your passwords again when they are fixed. In the meantime be aware of suspicious activities; your data may have already been compromised.