All about the Heartbleed bug and how to protect yourself

There are three people you should thank right now:

1. Neel Mehta of the Google Security Team
2. Adam Langley from the Google Chromium Team
3. Bodo Moeller of the Association for Computing Machinery

Both Adam and Bodo work for Codenomicon and coined the name Heartbleed to describe their discovery of the cataclysmic bug that is currently affecting millions of web applications around the world.

The bug is technically known as CVE-2014-0160 and according the internet services firm Netcraft, over 66% of all the webservers in the world are affected by the Heartbleed bug.  That’s approximately half a million widely used websites that are now vulnerable.

And guess what?

Yahoo was one of them.

Yesterday, Yahoo told CNET:

As soon as we became aware of the issue, we began working to fix it. Our team has successfully made the appropriate corrections across the main Yahoo properties (Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr, and Tumblr) and we are working to implement the fix across the rest of our sites right now. We’re focused on providing the most secure experience possible for our users worldwide and are continuously working to protect our users’ data.

Shortly after 3PM EST Yahoo plugged the hole; however, the point is that not even big sites with big budgets are hermetically sealed from the implications.

I mean, yesterday, Joost Bijl of Fox-it security, posted the censored results of the actual exploit of Yahoo’s servers:

In the right column of the screenshot, you can actually see the login names and scrubbed passwords of real Yahoo users.

This is no joke.

But Yahoo isn’t the only one affected.

You can peruse a list of the top 10,000 sites in the world vulnerable to Heartbleed.  You might be find surprised at who shows up in the list.

Imgur, OKCupid, and LastPass were all running affected versions of the OpenSSL cryptographic libraries but thankfully all three companies have mitigated the threat.

What’s the big deal?

The Heartbleed bug enables an attacker to covertly retrieve data in 64KB chunks from random memory locations on the server.

Admittedly, the culprit has no idea what he’ll get from that 64KB memory block (it’s like blind fishing); however, when the attack is iterative it becomes extremely dangerous because all sorts of sensitive stuff sits in memory…

• Private Keys
• Passwords
• Credit Card Numbers
• Session Data

For nearly two thirds of the webservers out there, the integrity and confidentiality of data is at risk.

An attacker could discretely eavesdrop on “encrypted” conversations or even masquerade as the server fooling unsuspecting users into divulging sensitive data.

When the servers private keys are compromised encryption because futile.  In Public Key cryptography, only the private key can decrypt an encrypted message; but when the private key is exposed – encryption is rendered useless.

But it’s actually worse than that.

Matt Sullivan made a cogent demonstration on how easy it is to completely hijack a users web session with the vulnerability.  Session hijacking means the attacker basically has a magic cookie giving him unfettered reign on authenticated web sessions.

In short, the HeartBleed bug gives an attacker carte blanche access to anything sitting in the servers memory.

Clearly the ramifications of exploitation are abysmal.

The root issue

The root of the problem is what coders refer to as a buffer overrun or “missing bounds check”.

Let me explain:

OpenSSL is an open-sourced library that provides cryptographic functions to millions of web applications.

In OpenSSL versions 1.0.1 through 1.0.f, there was a new addition called the TLS Heartbeat Extension.  You can read the pedantic RFC on the IEFT’s website; but I’ll spare you the boredom.

Just think of it like this:

Just as your physical heartbeat keeps you alive with each beat, so the TLS heartbeat tells the client and server that the encrypted session is still active.  This is especially important when no data is being exchanged because both computers need a way to make sure the other one is “still there”.

When the server received a HeartBeatRequest message it has to send a corresponding response carrying an exact copy of the payload it received in that request.

But here’s the vulnerability:

If the attacker sets the length of the payload to a value greater than the actual payload size any data sitting in memory after the payload will automatically get copied in the HeartBeatResponse packet.

So in vulnerable versions of the OpenSSL stack, an attacker can craft a benign heartbeat request of a relatively small size but then surreptitiously set the length of the payload in the data packet to something like 0xFFFFF.

So what?

Well 0xFFFFF is hexadecimal for 65,535 bytes.

When the server receives this jumbo heartbeat packet is indiscriminately copies the heartbeat request to memory but also any other bits of memory sitting next to it get dumped in the response.

In other words, any sensitive information sitting in the difference between the payload length value and the actual payload itself is returned to the attacker as a 64KB memory chunk in the next heartbeat.

That’s why this is called the HeartBleeder attack because the bug makes the server bleed it’s sensitive guts to malicious hackers.

Ramifications

Jamie Blasco, Director at research firm AlienVault Labs says that this bug has “epic repercussions”.

It’s epic because changing your passwords – although a necessary next step isn’t sufficient.

Affected providers such as Yahoo, OkCupid and millions of others, need to not only patch the security flaw but also replace the compromised keys and certs.  This entails revoking those adulterated certificates and reissuing new ones.

The enormity of this breach cannot be overstated.  And the nature of this threat is such that it leaves no evidence of exploitation.  In other words, when an attacker executes the attack there’s no indication in the logs that the server was even victimized.

Certificate owners and service providers need to check with their Certificate Authorities (CA) to see how to revoke and reissue their keys.

What should I do?

Three things:

• Change your passwords
• Delay logging into sites that have your personal information for a few days
• Test the site for vulnerabilities

Change passwords

This is obvious and onerous but it’s imperative.

Facebook, Tumblr, Yahoo, Google – everything needs to get a password refresh.

But don’t just change it… you also need to make sure your passwords are both strong and unique.  And don’t share the same password across multiple sites.

That’s why I use LastPass for this kind of thing because it’s a secure means of storing and protecting your passwords… and it’s free.

Abstain from the web

In addition, I suggest abstaining from any sites that hold personal information.  We need to wait a few days for the major sites to revoke and reissue their vitiated certificates before we login again.

There’s no point in changing your password and then logging into a comprised server only to have it stolen again.

Test sites yourself

Finally, you can test websites for the Heartbleed bug by entering the URL into Filippo Valsorda’s Heartbleed tester.

The Bottom Line

The Heartbleed bug has actually been effectual for over two years, specifically according to Codenomicon, since December 2011.

<shiver>

Given the ubiquity of OpenSSL, with that kind of exposure for such a long time at least one of your accounts has a high likelihood of being compromised.

The Heartbleed bug is a sweeping problem that was either a programming mistake or a volitional act of malice.

I want to believe the former; however, I have no evidence to support my belief.  Apparently, I’m not the only one who shares this sentiment.

On his blog, the preeminent security expert Bruce Schneier muses that we’re all asking the wrong question.  He ruminates:

The real question is whether or not someone deliberately [emphasis mine] inserted this bug into OpenSSL, and has had two years of unfettered access to everything. My guess is accident, but I have no proof

This obviously veers in the realm of speculation but it’s an intriguing thought…

We know the German software developer who worked on the code containing the Heartbleed bug claims he “unfortunately missed” the bug two years ago.  But it’s odd because the developer, Robin Seggelmann, is also one of three authors who worked on that RFC 6520 specification.

There’s a lot of speculation on Hackernews about this but nothing substantive so you should but your judgment in abeyance.

But I wonder….

Who knows.

Maybe we should just scrap all our computers and go back to the stone ages when Tablets were actually tablets of stone.  That would obviate all our security problems right?

Well, we’d have to worry about people stealing our tablets then but… I digress.

Seriously – I really wish there was a happy ending to this debacle; however, the truth is it’s going to take months to clean up the collateral damage.

The Heartbleed bug is a sober reminder that we live in an interconnected world where one mistake can have devastating effects for millions of people.

Refresh your passwords, take a break from the internet if you can and see if the website you’re trying to access is vulnerable before logging in.

Oh, and please share your thoughts in the comments!