Heartbleed has captivated the attention of the internet in the past few days since its discovery and that’s no coincidence. It’s bad news. Like, really bad news. It’s not necessarily a good thing when Joe Siegrist, the CEO of LastPass says, “It was definitely a ‘holy sh*t’ moment”.
Now that it’s been a week since the initial shock of learning about the Heartbleed bug, I wanted to cover what the security community has learned and convey what some of that means to “non-techies”. As a web developer/designer and an open-source software enthusiast, I hope to shed some light on this topic for the people out there that still have questions about what they should do and how Heartbleed affects them.
In this, the Ultimate Heartbleed Guide for Non-Techies, I want to discuss the following important questions that I think a lot of people have about Heartbleed:
- What is Heartbleed?
- Why is this so dangerous?
- How widespread is the issue?
- How do I protect myself and my data from it?
- Why did Heartbleed happen?
- How long have people known about Heartbleed?
- What is being done about it to prevent it from happening again?
What Is Heartbleed (in a nutshell)?
Heartbleed is a buffer exploit built into the OpenSSL standard (many say by accident) that first showed up in edits made at 11:59 PM on New Years Eve 2011 by German programmer Robin Seggelmann. OpenSSL release 1.0.1 was made publicly available on March 14th, 2012. The vulnerability works by exploiting buffer underflow on the Heartbeat command across TLS channel communication link between a client and a server where the server doesn’t exactly validate the incoming command’s size request. Let’s take a look at these diagrams:
In this first diagram, we see a clean TLS (Transport Layer Security) channel communication from a client to a server. A message is sent from the client: “Hello” and attached to the message is a piece of data containing how big the message is, in this case “5” characters. The server receives this information and returns it with the exact, expected response. This is a typical “Heartbeat” communication.
Now let’s look at a corrupt transmission with a Heartbleed exploit tool in place.
In this diagram, the exploit tool has now modified the size description of the message to read “23” characters, which is 18 more than the message “Hello” contains. The mistake in the code allows the message to come in and the server doesn’t verify or validate this size description information at all on the response, so it now will send the original response of “Hello” plus an additional 18 characters of whatever happens to be in memory at that time. In the diagram above, the attacker will receive the original “Hello” response plus “SecR3tPsswRDz!1337”.
This is a quite simplified description of the attack itself and it’s actually much more complex than this, but the principle remains. Next in the guide, we’ll discuss why Heartbleed is so dangerous.
Why is Heartbleed So Dangerous?
Any leak of personal information at the server level to unwarranted parties is dangerous, but in particular Heartbleed is bad because the thief leaves no trace behind. As described in the previous diagrams, this exploit affects memory, or the information that is stored in the RAM on the server. If you’re familiar at all with RAM, that information is dynamic and is stored temporarily. The exploit dumps 64 Kilobytes of data as a “snapshot” of RAM at the time that the user requests it.
That may not seem like a lot of data in this day and age when everything is measured in Gigabytes and Terabytes, but you have to remember that most sensitive data, like a password, would be stored as plain text (only the dumbest system admin in the world would do this, but it’s been done before) or a hash, which takes up a fraction of the space that pictures and movies do and would easily fit inside 64 KB of data. To put things into perspective, to download the entirety of Wikipedia (13.9+ million pages) as plain text without graphics and images, would take up 25 GB as of 2013. Add the estimated 3.7+ million thumbnails to that and you’re looking at around 100 GB of data or almost 4x as much!
Side note: still very impressive that all of Wikipedia could fit on a 128 GB SSD! Want to download it? Go here.
It should also be noted that 64 KB of data isn’t the limitation of the entire attack, but the limitation of the attack per heartbeat. The attack could continue for as long as the attacker wished and that could amount to a lot of data. Unlike other exploits that can be detectable on the kernel of an operating system or in the logs of a network device, Heartbeat requests are naive and therefore, Heartbleed leaves no log events behind. It deals with what’s in the system memory so security experts have to be clever about finding ways to detect intrusions. Later in this guide, I’ll talk about what systems admins are currently using to trap Heartbleed attackers.
How Widespread is Heartbleed?
Most of the headlines have read something like: “Heartbleed: The Internet’s Biggest Nightmare” or “Heartbleed is the Worst Bug The Internet Has Ever Seen”. Where Y2K was all hype, this is at least substantiated into a legitimate threat and it’s already done more damage than Y2K ever did. Canada’s Revenue Agency posted an update that they were affected and subsequently suspending e-filing of taxes. CRA now says that they’ve patched their site, but how much has that cost the country of Canada? Further, how much has it cost the rest of the world’s businesses when you factor the amount of time and energy spent on tracking this bug and patching it?
It’s tough to put an exact number on how many websites are actually affected because OpenSSL figures vary. Some figures claim that only about 19% of the internet uses OpenSSL whereas others state it’s as high as 66%. In all actuality, it’s probably somewhere in the middle. Initially after any huge catastrophic event, information overload occurs. That often leads to false reports, misinformation, or even outright lies. CloudFlare even stated that Heartbleed might not be as bad as they initially thought, which caused people to drop their guard. Immediately that information was crushed when they crowd-sourced testing on Apache servers and on the first attempt, the private keys were leaked. CloudFlare then recanted the statement.
It’s difficult to find information you can trust, but here are some points that you absolutely can trust:
Major Internet Sites (e.g. Facebook, Google, Yahoo) Were Compromised
If the site used OpenSSL 1.01 – 1.01f, the site was at risk. A lot of web services used OpenSSL for its flexibility. While systems administrators are still auditing their sites to check the depth at which they’re compromised and patching their systems, its safe to assume that if they used OpenSSL, they were affected to some degree and if you’re a member of that site, you should plan on changing your password as soon as their site is patched.
Most Online Banks and Credit Union Websites Don’t Use OpenSSL
Open-sourced software can be great (take WordPress for example), but that doesn’t mean that there aren’t drawbacks to it as well. One of the arguments against open-sourced software is the ability to exploit it and this is true in the case of OpenSSL. Most banks and credit unions have been advised against using open-sourced software like OpenSSL for security reasons such as this to begin with and whether you agree or disagree with that on a principle level, it’s kept most of them safe from Heartbleed.
That’s not to say that you shouldn’t contact your bank and ask, head over to LastPass’ Heartbleed Checker and see if your bank’s site passes the tests, and monitor the situation closely. If you notice any strange activity on your account, notify your banking institution immediately.
Routers, Switches, and Other Network Equipment Has Been Compromised by Heartbleed
It’s not just websites that have been compromised. Cisco released a bulletin letting consumers know that certain equipment of theirs may be affected. Looking at the list, it appears as though it’s mostly commercial appliances, but if you’re concerned at all over whether your device is at risk you should check with your manufacturer at their website and see what they have to say.
Exploiting Heartbleed To Steal Actual Data Is Difficult, But Not Impossible
I already diagrammed a very simplified process of a Heartbleed attack above and that’s generally the principle: get the server to send you more data than you requested so you can sift through it later and find something valuable. But that’s much easier said than done. To read more about how difficult it is, check out this article from ThreatPost and realize that private keys aren’t exactly low-hanging fruit, but reports about them being impossible to steal are downright incorrect.
Open-Sourced Software Is Not To Blame, Human Error Is
April 7th, 2014 marks possibly the darkest day in the history of open-sourced software. It’s unfortunate that due to multiple points of human failure, the entirety of open-sourced software might suffer.
How Can I Protect Myself From Heartbleed?
Well, this is tricky because right now there might not be much you can do. The proper thing to do is to change your password on every site that used OpenSSL 1.01 through OpenSSL 1.01f since it’s a possibility that your password could have been compromised. However, a site could have been running OpenSSL and still not had Heartbeat enabled, which would have protected the user from Heartbleed and it’s important that you don’t waste a bunch of time jumping from site to site changing your password before that particular site is patched to OpenSSL 1.01g.
You should definitely keep up to speed on the list of sites that are patched. I’ve compiled a short list of some of the web’s most popular sites:
| Site | Affected by Heartbleed? | Is It Patched Yet? | Should You Change Your Password? |
|---|---|---|---|
| Yes | Yes | Yes | |
| No | Yes | To Be Safe – Yes | |
| No | No | No | |
| YouTube | Yes | Yes | Yes |
| Yes | Yes | Yes | |
| Netflix | Yes | Yes | Yes |
| Dropbox | Yes | Yes | Yes |
| Amazon | No | No | No |
| eBay | No | No | No |
| PayPal | No | No | No |
Mashable has an “always-up-to-date” list located here and you should also go to LastPass and use their Heartbleed Checker tool to see if a particular site is compromised. Also, according to ARS Technica, even after those sites are patched, you should watch to see if (and when) they update their site certificate and change your password a second time to be extra secure.
Why Did Heartbleed Happen?
In short, it all appears to be an accident; a simple mistake that the programmer made in his code that went unchecked. What it boils down to is incorrectly validating input from the client and that’s as basic as programming gets. That’s not to say that even the most advanced programmers in the world don’t make mistakes in proper validation, because it happens all the time. However, usually the person checking your work also catches that error before it makes it out into the wild.
On April 11, 2014, the programmer responsible, Robin Seggelmann, came forward with a statement claiming that it was an accident. By all accounts, it seems like he’s telling the truth as nothing in his code seems malicious. The same as intent can be derived in a murder case, intent in malicious code can be derived by super-sleuthing hackers and it seems that the general consensus is that it was an honest, but very unfortunate mistake.
The update to the code, known as CVE-2014-0160 (CVE stands for Common Vulnerabilities and Exposures), was pushed to OpenSSL 1.01 on New Year’s Eve at 11:59PM, December 2011. The change went unchecked until OpenSSL 1.01 was released to the public in March, 2012. At that point, the change that Seggelmann made became committed to the code and the rest is history until the flaw was publicly revealed in April 2014.
How Long Have People Known About Heartbleed?
Officially, the public has known about it since Neel Mehta of Google Security released an advisory regarding the exploit. At that time, it’s difficult to say if it had been exploited in the wild before since Heartbleed leaves behind no traces. At that point, things proverbially “hit the fan”. Media outlets got a hold of it, the story spread across Reddit and the rest of the internet like wildfire and systems admins were scrambling to check whether or not their systems were vulnerable.
Should this have been kept quiet until the patch was already committed to the next update of OpenSSL or not? That’s quite a tricky subject. If it’s kept quiet, and OpenSSL genuinely controls 66% of the secure sites on the web as some sites claim, then you leave them all open and vulnerable to attack until they install the patch, which might not come for days, weeks, months, perhaps even a year or more. Going public with this information prior to having a patch in place most certainly expedites the sense of urgency and brings attention to the vulnerability that this exploit causes, but at what cost? Now with that public knowledge, black-hat attackers could attack those sites that are vulnerable while they’re awaiting a patch. Like I said, that’s a tricky subject and the answer isn’t so clear.
However, what’s done is done and now we’re just left picking up the pieces. Of course there are rumors that the NSA knew about Heartbleed and exploited it for years. The NSA has flat-out denied it, claiming that they found out just like the rest of us:
Statement: NSA was not aware of the recently identified Heartbleed vulnerability until it was made public.
— NSA/CSS (@NSA_PAO) April 11, 2014
At the end of the day, we’ll never know whether or not the NSA knew or if black-hat attackers knew. We should simply focus on getting this fixed now, and on how to prevent this in the future.
How Do We Prevent Things Like This From Happening In The Future?
Some people, including the programmer that made the error, have stated that the OpenSSL project is vastly underfunded and needs better funding to bring more resources on board to help mitigate issues like this through better proofing. This particular bug was a human error, left unchecked and committed to a major revision of code. It’s not exactly like this is preventable, regardless of how much funding you have or the amount of checks and balances your code goes through. Some things always slip through the cracks and this shouldn’t reflect poorly on open-source software as a whole.
It’s an unfortunate mistake that has cost a lot of time, money, and heartache. However, the silver lining here is that as Heartbleed.com mentions:
A lot of software gets updates which otherwise would have not been urgent. Although this is painful for the security community, we can rest assured that infrastructure of the cyber criminals and their secrets have been exposed as well.
For more information, visit the official Heartbleed website here.
