Ask The Cyber Security Expert: How bad is this internet encryption ‘Heartbleed’ problem?
On Monday 7th April 2014 the world woke up to what is being described as one of the most significant software bugs ever. Heartbleed, as the bug has been called (or more prosaically CVE-2014-0160), is clearly a big deal. To find out exactly how big, we interrupted The Cyber Security Experts morning ST:TNG binge and got him answering some questions.
How bad is this?
Pretty bad. The bug is in a piece of software (OpenSSL specifically) that provides encryption (i.e. ensures your data is safe from eavesdroppers) for approximately half a million secure websites, including banking sites, social media etc. The problem isn’t in the encryption itself; data going to and from those websites was well protected, but in the implementation of the piece of software. The bug allows an attacker to request chunks of memory from the targeted server, which can include user names and passwords, and even worse potentially the secret encryption keys themselves, on which the protection of data hinges.
Please explain!
This kind of programming bug is actually fairly common, but this instance has a particularly high impact. It is called Heartbleed because the flaw is in the ‘heartbeat’ mechanism that is used to verify connections between you, the user, and the servers (e.g. your bank) are active. The connecting software on your computer (such as your web browser) sends a random string of data to the server, which the server duly returns confirming the connection is up. This sounds simple, enough and indeed should be. However the devil is in the details. Programming languages are fussy about the length of bits of data – there is a big difference between the expected length of say a username, and your tax returns. All of the the elements of data that a server will be expecting to receive will be defined by the software developers and be allocated a certain amount of space in the computer memory when the software is running.
Now, the random string of data your web browser sends to the website you’re using can be up to 64Kb long (Kb stands for Kilobyte). When the web browser sends the random string of data it also tells the receiving website how long the random data is. The server running the website allocates some memory, and stores the supplied data in it. It then reads and returns the data to your computer, and the heartbeat process is complete. Unfortunately nowhere in the process is the amount of data supplied to the web server actually checked, which leads to the problem at hand.
Someone acting maliciously can tell a vulnerable web server they are about supply 64Kb of random data for the heartbeat. They can then supply 1Kb of data. The 1Kb of data is stored in the server memory and then, as the second part of the heartbeat process, it is returned to the sender. However because our malicious actor told the server they were going to supply 64Kb of data, it returns that much data. In this example that would mean it would read the 1Kb of data actually provided from its memory, and then 63Kb of data which could contain anything.
So what does this mean in practise?
It varies. The random data returned may be completely innocuous, or it could contain something juicy. It’s not possible for the attacker to specify what gets returned, but by making lots and lots of malicious requests they can potentially read a lot of information stored in memory on the web server. Twitter was full of examples of Yahoo usernames and passwords that had been acquired in this manner, which makes sense as Yahoo probably has thousands of users logged in at any one time and hence random requests for memory are likely to return some of their details.
It is possible that the secret keys that are vital to encrypted connections could be acquired in this way, and indeed researchers have demonstrated this is possible. It is not clear how easy or practical this would be outside of a laboratory, on a busy website. Equally, although it was disclosed this week, at the same time a fix was available, the bug has been around since late 2011. It is hence possible that it was discovered, kept quiet and has been used maliciously for some time.
If you run a secure website you need to see if it is vulnerable, either by checking the version of OpenSSL running, or using one of the many tools that are now available (there is an online version here). Once fixed, you need to make a decision about generating a new public/private key pair, and getting a new certificate issued from your friendly Certificate Authority. This approach might seem like overkill but it may well be the only way to reassure your customers. This bug is now certainly being exploited for malicious purposes, so if you have been slow to fix it, this is probably the best course of action.
If you are an end user then the advice varies. I would not rush out and change all passwords immediately. Ideally check with the services you use, and take the advice they give you. Firstly the site might not have been vulnerable at all, and secondly there is no point changing the password if the website is vulnerable and not yet fixed. For websites that confirm they had the issue, and have fixed it, I’d take the initiative and change the password (a password manager can help with this – I talk about using those here).
Is there anything else I should do?
Yes! Enable two factor authentication everywhere you can! We’ve talked about this before (here). It mitigates all this worry completely – even with your user name and password stolen your accounts are safe.
Secondly – DO NOT click on any links in emails you get telling you to change passwords. I can’t emphasise that enough. This issue is the perfect fodder for criminals looking for the latest hook to target people and steal their online credentials. If you do get an email that seems to be from an online service, visit the service website using your browser by typing in the address e.g. type www.amazon.co.uk into the browser rather than clicking on a link in an email. It is surprisingly easy for someone to spoof email, and put up a fake website.
The upshot, for the average user, this isn’t the end of the world. The fix was out quickly, and the chance of you specifically falling foul through exploitation of this bug is low. However, we rely on online services a lot – password changes for services that were affected, and are now fixed are prudent. Turning on two factor authentication for additional security where it is available is a must.
Which episode of ST:TNG were you watching?
As always thanks for reading and please get in touch if you have questions.
Find us on twitter, or use the contact form.
The Cyber Security Expert