Heartbleed...

[PXW]

Any of the IT experts here able to give a sensible view on this? I've only seen the DM report which I, perhaps harshly, suspect may be ever so slightly sensationalist. So, is this a clear and present danger whereby "they" have access to all passwords from, inter alia, Lloyds and Nationwide, or is this just the latest revealed security weakness that will cause the IT departments to rush about a bit while they install a fix?

 

[Troon]

No, this is really serious. Basically, for the last two years, many sites secured with SSL (HTTPS) have actually been wide open for the baddies to read server memory at will and with no trace.

SSL has a "feature" called the heartbeat. The client (your PC) can send a signal to the server to ensure the connection is still live. Simplistically, it can say "ping! (5 bytes)" and the server will return "ping!". The bug in the popular open-source OpenSSL library just announced means that the client can say "ping! (10,000 bytes)" and the server will return "ping!aoihW OGH20804HO (etc)", where all that extra stuff is whatever happens to be in the server memory immediately after where it stored the ping, with no protection at all.

That memory could contain, for example, usernames and passwords just submitted by users; secret keys; pretty much anything. It's not targetable: the attacker gets a random slice of memory — but he can do this, up to 64kB at a time, as many times as he wants, without any trace being left.

For example, you type your online banking user name and password in, the server will store that in memory prior to checking for a match — if the attacker happens to get given that bit of memory, he has your username and password.

In another, potentially worse scenario, he could get the service's SSL private key, and pretend to be your online bank. The padlock and "https" that you're used to trusting now mean nothing.

Although it's been announced now, and important sites are rushing to fix it (yesterday was an "interesting" day for those with online services), the concern is that this has been around and potentially known about for two years.

The recommendation to change all passwords is a good one; and if a service you use announces they were vulnerable and have now fixed it, go change your password on that.

Bruce Schneier, a security expert not known for hyperbole, rated this as an 11 on a scale of 1 to 10 for severity.

 

[kingdave]

Is it really a good idea to change passwords today?
The vulnerability is still there in nearly all of the systems and you would potentially seed the memory with your details by logging in making it available to the baddies.

Preferable to hide offline for a bit?

 

[Sp!ke]

Good question.

Surely changing passwords on an account without knowing whether the server holding the account has been patched yet or not would be increasing the risk.

First you need to know somehow that it is safe to update your passwords with that particular server and I'm not sure how one can tell.

 

[Troon]

First you need to know somehow that it is safe to update your passwords with that particular server and I'm not sure how one can tell.

Test your server for Heartbleed (CVE-2014-0160)

 

[Halcyon Days]

Big point - it is only OPENSSL that is at risk, not all sites that use HTTPS (So, for a change, Microsoft aren't affected)...

Does your bank use Apache? (Probably not)
Does it use 2 level authentication? That mitigates the risk a lot.

If your company uses an IPS, that uses Snort, there is a rule that will block miss-matched packet sizes in heartbeat requests.

As far as personal worries go.. Don't change your password until the site is verified as patched.
If you use Chrome, change the default setting about revoked certificates to "yes"
Check your bank statements regularly.

 

[Dryce]

No, this is really serious. Basically, for the last two years, many sites secured with SSL (HTTPS) have actually been wide open for the baddies to read server memory at will and with no trace.

That memory could contain, for example, usernames and passwords just submitted by users; secret keys; pretty much anything. It's not targetable: the attacker gets a random slice of memory — but he can do this, up to 64kB at a time, as many times as he wants, without any trace being left.

For example, you type your online banking user name and password in, the server will store that in memory prior to checking for a match — if the attacker happens to get given that bit of memory, he has your username and password.

Reality check.

While not playing down the fact that this hole has to be closed - the actual stuff you get back could be *anything* - and you might not be able to identify what's actually of use to you and what isn't. So yes a user password could potentially be exposed - but chances are it would be one 'in flight' and that's not the same as exposihg all passwords from a database.

So while everybody goes "OMG I'm vulnerable" after using the vulnerability checker that doesn't mean that they've actually exposed or that they will actually will expose anything.

The reason that it's significant in professional terms is that it 'could potentially' which means risk. And security professionals tend to treat any 'could potentially' vulnerability as something that has been or will be usefully expoited by the bad guys.

As usual the finger gets pointed at the security agencies to say they have all the private keys. Well there's no guarantee that this will expose a private key and there's no guarantee that the security agencies are any more aware of this issue. Moreover the stories about these organisations tend to suggest they have other means (don't they always?).

The real question is whether keys and passwords should be updated. That's a whole lot more stuff being touched. For organisations that hold anything remotely sensitive who can't demonstrate that information has not been exposed they will have to evaluate the risk vs damage/liability and respond accordingly.

Now if I was a security agency what I'd actually do if I was aware of this issue would be to exploit the fact that organisations I was targeting were going to update their systems and treat *that* as my window of opportunity by forming a strategy to capitalise on that as a way of getting what I might deniably want.

Turning this about - if you were a security agency that had mined target systems and obtained keys using this vulnerability on your enenmy would you then have your own government discretely patch its systems? If you do that then they are protected from the enemeny that have the knowledge. OTOH by patching your systems you are eventually letting the enemy infer that you know ..... and thereby inferring that you are actively exploiting it ......

 

[Troon]

Reality check.

While not playing down the fact that this hole has to be closed - the actual stuff you get back could be *anything* - and you might not be able to identify what's actually of use to you and what isn't. So yes a user password could potentially be exposed - but chances are it would be one 'in flight' and that's not the same as exposihg all passwords from a database.

This is true, although an attacker can repeatedly request 64kB chunks without leaving a trace. It's been shown to be quite likely to receive e.g. HTTPS decoded data showing usernames and passwords.

It is much more of an issue for people running services than people using them, though. I'm in the former category and have had an interesting 48 hours: patch, reboot, renew SSL certificate, revoke the old one, inform key users. Luckily, my server is nothing financially-critical or super-sensitive.

 

[scillyisles]

Test your server for Heartbleed (CVE-2014-0160)

This is rubbish - looks to me like some test software written by a freelancer. God knows what it does. It might even be spyware/virus.
The best test I have used is the Qualsys test which produces a much better analysis.

 

[Troon]

This is rubbish - looks to me like some test software written by a freelancer. God knows what it does. It might even be spyware/virus.
The best test I have used is the Qualsys test which produces a much better analysis.

The filippo.io test is indeed written by an "enthusiast" (from his site, an Italian consultant specialized in cryptography and security with a passion for Python and maths), with source and a full explanation provided. It was the first online test readily available: if a vulnerability is detected, it shows how this was detected.

Why do you think it's rubbish? Because it's large, clear and easy to use? I'd be interested to hear how entering a domain name into a form field can count as "spyware/virus"...

Qualsys has only recently started evaluating for Heartbleed vulnerability, and is much slower than the other test if that's the only thing you're interested in. It wouldn't surprise me if Qualsys are using the code from the filippo.io test themselves. Incidentally, my service scores A+ at Qualsys, so I have a vague idea what I'm talking about...

 

[scillyisles]

The test fails on all the sites I tried with an error indication "Uh-oh something went wrong" which tells you nothing. So much for your clear easy to use explanation.
Glad to see you are using the Qualsys tool which provides a much better analysis but does take longer. This tool has worked on all the sites I have tried.
As for your comment about might knowing what you are talking about - I agree you seem to have a modicum of knowledge but your first post on this subject was somewhat lacking in detail and rather alarmist. For example the heartbleed feature whilst implemented in the Open SSL stack is not widely used in websites. Your post was somewhat scaremongering as Dryce suggested in his post.
.... and yes I might have a modicum of knowledge in this area too.

 

[markmifsud]

as has already been said. The issue is thats its possible to read the servers ram. As far as I know, there is no access to the DB. This is a real issue but I am not sure it was heavily exploited other than on the Yahoo servers, and lets be honest, who uses yahoo these days.

I have patched all my linux servers that are running SSL.

 

[AshC63]

This is another example of 'nothing is impossible'

Always sceptical when someone or some company qoute they are bolt proof & yet time & time again ...this proves not to be the case .

Fascinating in a weird way ... Today's technology & tommorow criminals .

Excellent explanation from Troon!

 

[edstrom76]

A few sites affected/unaffected here: http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/