The servers/Their server. Yes that's what I was intending.
OK, well they basically pen-tested their own server, externally, with limited information.
Just the opposite for Google. Heartbleed – What passwords to change
By ASP.NET, I basically mean that any website on the internet that is running Microsoft web stack is immune to the problem, because they don't use the OpenSSL SSL implementation
What makes this so frightening is that for all we know there was absolutely zero data "stolen" before the exploit was patched. On the other hand for all we know 3\4 of the websites on the internet could have had data stolen. Or somewhere in between...
The Data stolen would only be what get's transferred through HTTP. So the idea that peoples passwords can be stolen from servers is actually not true- the only thing that can be stolen is data in the server processes memory or data transferred from client to server.
Any good implementation of security will never store passwords in plaintext; they will be stored as a salted hash. That salted hash might be acquirable, but it can't be reversed back into the password. It's arguably easier to find the password or a password but it's still fairly intractable- without knowing the Salt it's practically impossible to find a matching Hash.
So users passwords can only be stolen by a Man in the middle attack done on a server that has had it's private key acquired by exploiting the bug.
1. I want your password for Bank.com
2. bank.com uses a version of OpenSSL that has the vulnerability. (Note: this appears to be restricted to servers running on Apache that use OpenSSL (as opposed to GNUTLS)- Servers that run Java Server Pages don't appear to be affected; and sites that run Microsoft's IIS Server as well).
3. I send requests and get pieces of the memory of the Process hosting OpenSSL (usually Apache)
This is already a difficult step, I think; you have to keep hitting the server to get pieces of it's process memory- How do you recognize the Server's private key? How do you know how it's stored? etc. But let's assume this is calculable in some fashion. So now we have the servers private key.
That's the end of the actual heartbleed bug. That's all. The most you can really get are Private Keys for the SSL server itself. There might be some information within the process memory, but you won't get free access to any passwords unless the implementation of the site itself is already insecure and storing them in plaintext. Usernames, possibly, but those aren't really that useful in and of themselves.
The "exploit" part is simply using that Private key to descrypt SSL transport streams. Man in the Middle attacks aren't exactly trivial- it get's decrypted and I search through the communication to find where your browser sent the server the username and password. And now I have them.
Agreed and agreed. A Google researcher reported it yet Google has had zero comments-warnings and Google has let the other company take all of the credit. Just doesn't add up.
Google has been threatening to quit working with the NSA. 1 + 1 = 2....
It was reported by three engineers who worked for Codenomicon. They were testing a Protocol security suite and found the problem when they implemented TLS support. I can't find Neel's story on how he found it, just how he donated the bug bounty from a foundation.
As far as I can tell, Google's own services cycled their Private keys, so the steps I outlined above would have had to take place in a very short time.
From Day One i felt there's an underlying story we may never hear...too convienent.
This may turn out to be malware instead of an exploit. NSA Said to Exploit Heartbleed Bug for Intelligence for Years
And then this. It kind of supports my thinking of the whole story not being told. Man who introduced serious 'Heartbleed' security flaw denies he inserted it deliberately
In my opinion this is nothing but conspirational nonsense. Software get's bugs all the time, especially when they use inherently insecure languages like C and have a "meh" attitude towards auditing new commits. Never attribute to malice that which can be adequately explained by incompetence or mistakes.
The article's source is " two people familiar with the matter" what does that mean? Why should we trust them? if I say, "I'm familiar with Microsoft and I say they are harbouring biomechanically engineered turtle warriors" can I get an article written about that too? The rest of the article is based on this unsubstantiated premise. Particularly considering their own public-facing website was vulnerable until the recent patch. Seems if they knew about it they would have patched their own site.
