How bad is the Heartbleed bug, really?

[StewartR]

Just trying to get a sense of perspective here...

I understand how the Heartbleed bug works, in conceptual terms. Send the appropriate command to a web server running OpenSSL, and in return it will send you up to 64k of data from its memory. I also understand how that can theoretically be very bad. If the 64k of data which has been sent to the attacker contains your password, and if you use that same password elsewhere, then you could be very vulnerable.

I'm sure it's monumentally stupid from a software engineering point of view. I would have expected that any kind of rudimentary quality control process would have picked it up. A few years ago I used to manage a software engineering team and I would have been appalled if something like this had slipped through.

But how bad is it in the real world? I mean, that 64k of data which gets sent to the attacker is just a random chunk of the server's memory. It's not like a database with a defined structure which you can use to interpret the data. If there are usernames and passwors in there, they're not going to be identified as such. And if you send the command multiple times you'll get back multiple random chunks of memory which may or may not have anything in common and may or may not have changed between snapshots, so correlating the 'take' from multiple attacks would be very very difficult, if not harder.

So whilst it's theoretically bad, I can't see how it's actually that bad in practical terms. Am I being naive?

 

[neil_g]

http://www.talkphotography.co.uk/threads/openssl-vulnerability.537102/

 

[mid_gen]

Stealing of private keys from vulnerable systems has been demonstrated repeatedly now. It's possible that blackhats/governments have had copies of private keys and been doing all sorts of things to supposedly secure communication. They may have not, there's no way for anyone to know really.

As I've responded to all the people asking my opinion....just assume that your passwords are a matter of public record. Change them.

 

[neil_g]

just assume that your passwords are a matter of public record. Change them.

once you confirm those sites have been patched

 

[StewartR]

http://www.talkphotography.co.uk/threads/openssl-vulnerability.537102/

Sorry Neil, not sure how that answers my question. I've read that thread, obviously, but I was struggling to discriminate between the theoretical and practical sides of this. I understand it's easy for the bad guys to grab random bytes from the memories of web servers, but what I don't understand is how easy is it for them to do anything useful with that random data. It's not like the dump they get will contain any meta data to tell them what they've got .. is it??

 

[mid_gen]

When private keys begin with
BEGIN PRIVATE KEY
and end with
END PRIVATE KEY
and you have strings like
"&login=user&passwd=password"

It's pretty trivial to filter out the useful stuff. All proven and working. Cloudflare.net challenged people to steal private keys off a server they set up and several people did it within the first few hours.

 

[mid_gen]

Bear in mind it's not random memory, it's adjacent memory within the same process, so it's always data the webserver is dealing with.

 

[neil_g]

Sorry Neil, not sure how that answers my question. I've read that thread, obviously, but I was struggling to discriminate between the theoretical and practical sides of this. I understand it's easy for the bad guys to grab random bytes from the memories of web servers, but what I don't understand is how easy is it for them to do anything useful with that random data. It's not like the dump they get will contain any meta data to tell them what they've got .. is it??

sorry just didnt see the point of a separate thread.

it will give them meaningful data, a lot/some keys get stored as plain text in memory. bitlocker was a great example of that, if you hibernated a machine while bitlocker was unlocked the contents of the memory got written to the hibernate file. cue people having access to your bitlocker password if they got hold of the hard drive.

 

[boolean]

Neil - did you mean truecrypt, the way I understand bitlocker is the private key is on a server somewhere else in the world.

 

[neil_g]

Neil - did you mean truecrypt, the way I understand bitlocker is the private key is on a server somewhere else in the world.

nope, bitlocker. as found in win 7 ultimate.

they may have changed it by now but it was a very easy exploit.

 

[StewartR]

When private keys begin with
BEGIN PRIVATE KEY
and end with
END PRIVATE KEY
and you have strings like
"&login=user&passwd=password"

It's pretty trivial to filter out the useful stuff.

Crikey. I had no idea.

OK, it's pretty serious.

 

[st599]

The issue is not the passwords. Someone messing with your Flickr feed is annoying.

It's the keys. How do you know that the signed certificate reporting to be your bank's is? Or any major site where you may give your credit card details? Or your GPs transactions with your medical records?

 

[StewartR]

The issue is not the passwords. It's the keys. How do you know that the signed certificate reporting to be your bank's is?

I guess I'm probably like most laymen in that I'd never given that any serious thought. I mean, if I go to www.hsbc.co.uk then that's my bank ... isn't it? How easy would it be for a bad guy to set something up so that I think I'm looking at www.hsbc.co.uk but I'm actually looking at something else?

 

[neil_g]

fairly easy with DNS/host file redirects.

thats not the problem in this instance though.

 

[StewartR]

fairly easy with DNS/host file redirects.

Really? Why isn't everyone doing it all the time then? (I'm not trying to be argumentative - just curious!)

thats not the problem in this instance though.

But it is part of the issue, isn't it? I mean, in order to trick me into entering my bank account's password into a dodgy website, the bad guys need to do TWO things: (1) get me to go to the dodgy website, and (2) persuade me that it's actually the HSBC website. Stealing HSBC's security certificate via the Heartbleed vulnerability will help with (2), but they ALSO have to achieve (1). I'm hardly likely to enter my password into www.dodgy-website.ru, even if the security certificate says it's HSBC....

 

[arad85]

But it is part of the issue, isn't it?

No. The point is the heartbleed bug allows a hacker to read 64k of memory. In this memory could be the root keys, but also your username and password. That is, you have entered your password into your banks website, and the hacker has just read it out after you entered it on that website. Think of it like someone being able to take a photocopy of the first page of your personal letters, whilst they are in your house, without you knowing.....

 

[StewartR]

No. The point is the heartbleed bug allows a hacker to read 64k of memory. In this memory could be the root keys, but also your username and password.

Sure. But you're quoting me out of context here. I was responding to this:

The issue is not the passwords.... It's the keys.

 

[arad85]

Sure. But you're quoting me out of context here. I was responding to this:

You went on to say "in order to trick me...", so you are supposing that the information is used to trick you into entering data into a malicious website.

There are two problems with heartbleed.

• Loss of sensitive password information, given over a secure link to a trusted site. Heartbleed gives hackers this "immediately" and they can just log into your bank (or whatever) and pretend to be you as they have your personal information which was securely encrypted when you sent it over the Internet. They have to be lucky (or you have to be unlucky) that your details were on the site when they attacked it.
• Ability to impersonate a secure site without you knowing to gain your password. This is potentially worse as it will trick many people into giving their details without them knowing that there is an issue.

How the second of these would work is as follows.

• Keys are stolen from HSBC (or whichever financial institution has been compromised)
• Website with exactly the content of the site to be impersonated is setup in some dodgy country (call it the Federated States of Dodgy)
• DNS servers are broadcast a change of IP address that says HSBC is moving IP from x.y.z.a (the real machine) to b.c.d.e (in the Federated States...)
• Whilst the DNS change propagation occurs, some web traffic intended for x.y.z.a ends up at b.c.d.e. Anyone on b.c.d.e can see EVERYTHING that is being transmitted as they can act like the original site - even through https.... The user has absolutely no idea that the site is bogus as their web browser will tell them that it is legit.
• It will take many hours/days to rectify the DNS change notification. In this time, many people will have given their details in complete confidence to hackers on b.c.d.e. Unless you look at the physical IP address and cross correlate it with something like whois, it will be impossible to decide if the site is real or fake and noone will do that when they want to make a quick check on their balances.

Far fetched? Nope. Google had their DNS servers traffic hijacked and redirected a month or so ago: http://www.ispreview.co.uk/index.ph...fic-hijacked-and-redirected-to-venezuela.html and also note this gem in that text:

Last May 2013 it was revealed that someone had been using a similar method to stealthily hijack Internet traffic bound for the USA / other countries and redirecting it through servers in Belarus and Iceland, before sending the traffic back on its way to the original destination.

 

[Box Brownie]

In the case of online banking at risk what about those that use a hardware device to create a new 'key' number each time you access the site???

Oh incase it was missed elsewhere this site has checker for a sites SSL security and a Heartbleed checker https://www.ssllabs.com/ssltest/index.html

 

[arad85]

In the case of online banking at risk what about those that use a hardware device to create a new 'key' number each time you access the site???

That's a secondary level protection and is harder to hack. As is any that has a "Enter 3 characters from 7" each time you login or one that presents a personalised picture after your first username...

 

[StewartR]

• Keys are stolen ...
• Website with exactly the content of the site to be impersonated is setup ...
• DNS servers are broadcast a change of IP address that says HSBC is moving IP from x.y.z.a (the real machine) to b.c.d.e ...
• Whilst the DNS change propagation occurs, some web traffic intended for x.y.z.a ends up at b.c.d.e. Anyone on b.c.d.e can see EVERYTHING that is being transmitted as they can act like the original site ...
• It will take many hours/days to rectify the DNS change notification ...

Thanks. That's *exactly* the mechanism I was seeking to understand.

So in order to make use of any keys stolen via Heartbleed, the bad guys need to also take two other steps, namely (i) setting up a fake website to impersonate HSBC or whoever and (ii) hacking the DNS servers to route traffic to the fake site. That sounds like a lot of work. And the article you linked to implies that such exploits might be detected relatively quickly, because there are mechanisms in place to monitor changes in Internet traffic routing.

It sounds like just using any IDs/passwords stolen via Heartbleed would be more productive.

 

[arad85]

It sounds like just using any IDs/passwords stolen via Heartbleed would be more productive.

For the casual hacker - yes, for the more organised, the impersonation route may be more productive - especially if they can also take over your e-mail (password resets etc...). You only need to harvest a small percentage of the total to make it (very) worthwhile. An d with the keys, you can probably do it repeatedly if you can route via a country that is more lawless when it comes to cyber crime....