Computer Hope
Other => Computer News => Topic started by: PCdoc on April 10, 2014, 12:24:36 AM
-
Web administrators and computer security researchers on Tuesday scrambled to fix a serious vulnerability in OpenSSL encryption used by thousands of web servers, including those run by email and web chat providers. The bug, dubbed Heartbleed, "allows anyone on the internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software".
Read full story (http://timesofindia.indiatimes.com/tech/tech-news/Panic-on-web-as-Heartbleed-bug-leaves-millions-of-users-vulnerable/articleshow/33464218.cms)
-
So, we'll have to careful as to which sites we visit.
-
Site Tester... (http://possible.lv/tools/hb/?domain=gmail.com)
-
So, we'll have to careful as to which sites we visit.
More important is what sites you visit and have to log in to. Don't change any passwords anywhere until an internet wide fix has been announced or you are 100% sure the website isn't on one of the compromised servers. It's best to not even visit your financial websites until a fix is confirmed. Use in person or phone banking for the next few to several days.
Site Tester... (http://possible.lv/tools/hb/?domain=gmail.com)
More...
LastPass Now Tells You Which Heartbleed-Affected Passwords to Change (http://lifehacker.com/lastpass-now-tells-you-which-heartbleed-affected-passwo-1561522244)
Also. Heartbleed Test - Enter a URL or a hostname to test the server for CVE-2014-0160 (http://filippo.io/Heartbleed/)
-
analysis (http://nakedsecurity.sophos.com/2014/04/08/anatomy-of-a-data-leak-bug-openssl-heartbleed/)
Fundamentally, it is a Buffer overflow exploit; by sending a reply to the server when connected via SSL and crafting the packet to say you sent a larger value than you did, the server will read beyond the end of the read buffer that was sent, and will send you arbitrary data from the server memory (whatever happens to be beyond the actual buffer, limited to around 64K.
It is called Heartbleed, as the article explains, because it lies in the logic used to handle TLS heartbeat replies.
What is actually returned is usually just random garbage; it's tricky to actually make use of it. However it's still a lot of data nad it is essentially just arbitrary data, so it could be anything OpenSSL was responsible for dealing with. In particular, server-side Private Keys.
Of note is that even with the Server-Side Private key, a malicious actor would still need to perform a man in the middle attack on an ongoing SSL transaction. With SSL the client get's a public key from the server, and that get's used to encrypt a generated session key, which the client sends back to the server; all transmissions now use that session key (which can be decrypted by the server's private key).
Therefore, in order to gain access to the information being transferred, a malicious actor will have to perform a man-in-the-middle attack on either the client or the server, log or otherwise track the encrypted data, decrypt the session key init with the public key they meticulously gleaned by sending carefully crafted SSL heartbeat packets to try to get the correct data in that 64K window and understanding how to recognize the public key amongst the memory garbage; then decrypt the session information itself.
Of course the problem here is that SSL is designed purposed almost specifically to combat man in the middle attacks to begin with, but has been ineffective at doing that for the majority of sites for the last two years; though most sites probably didn't update to the latest OpenSSL until some time afterwards (March 2012 being when the vulnerable version of 1.0.1 was released).
According to the commit history, this particular change was committed by somebody with no security experience; the 'payload' feature which is at the core of this exploit was completely unneeded to implemented TLS, but was, according to the notes, for "flexibility".
I find that a bit troubling; Open Source is fine and all but once you start getting huge numbers of users that depend on the stability and correctness of your product you should probably start auditing new commits.
-
Hey BC. What stands out to me is that the researchers who found this are not your normal "bug bounty" researchers. Wouldn't finding this exploit indicate that these guys had administrative access to the servers to begin with? I'm not trying to downgrade the threat but it seems like this isn't something that just anyone could exploit.
-
This is a brilliant explanation of how it works from XKCD:
(http://imgs.xkcd.com/comics/heartbleed_explanation.png)
Source: http://xkcd.com/1354/ (http://xkcd.com/1354/)
-
Wouldn't finding this exploit indicate that these guys had administrative access to the servers to begin with?
It was probably just a case of "what happens if we do this?"; possibly prompted by looking at the code and noticing the flaw. Buffer Overflows like this are pretty much the most common security issues that appear; if you ask me it comes down to how so much software is written in C/C++. It's basically as described in the comic cam links. The client will pass in information as well as a payload size, and the server trusts the size given by the client (which is an issue...) and then uses that specified size to copy memory and returns that to the client.
I'm not trying to downgrade the threat but it seems like this isn't something that just anyone could exploit.
That was kind of what I was getting at with the Man in the Middle mention; If for example somebody wanted to get access to my bank account login, they would need to use the exploit on my banks website, which means a unpatched/old version of SSL would have to be being used. Then they have to keep performing the exploit and trying to figure out the memory garbage that is given back in the hopes they can find the Server's Private Key- very much like finding a needle in the haystack, though I'm sure it could be automated with a script or other tool.
Once they have that private key, they can decrypt active sessions. If they can get access to the encrypted data being exchanged between a client and server, they can decrypt it and read it, basically as plain-text.
So there would definitely be a lot of work involved, though hackers aren't well known for being short on spare time.
-
Another thing that stood out to me from what I read is it sounds like the guys who found this were publicly blogging (bragging) about it almost immediately. Exploit researchers, especially those from companies like Google, know better than to go public until a patch is in place. They bragged well before the patches were being reported so that is something else that tells me they had to have had some sort of elevated access to the servers. I don't know though. It just seems like some of the story isn't being told.
-
As reported by KTVU, TV station in San Fransisco.
http://www.ktvu.com/ap/ap/business/online-security-flaw-exposes-millions-of-passwords/nfWRH/
-
They bragged well before the patches were being reported so that is something else that tells me they had to have had some sort of elevated access to the servers.
What Servers (???)
-
Is OpenSSL encryption not server based? (I'm showing my level of knowledge now lol).
-
Is OpenSSL encryption not server based? (I'm showing my level of knowledge now lol).
Well yes but it is going to be on different servers, it's not like a centralized OpenSSL thing- each site deployment has a different setup.
Interestingly, ASP.NET websites are immune to this bug.
Mostly I was confused by the use of "the servers"; from what i can tell they did gain access to their own server with OpenSSL installed, and were able to get private data from the server, which seems to be what the current heartbleed website derives it's information from (followed by further tests with public servers).
-
The servers/Their server. Yes that's what I was intending.
Interestingly, ASP.NET websites are immune to this bug.
Just the opposite for Google. Heartbleed – What passwords to change (https://www.ivpn.net/blog/heartbleed-passwords-change)
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...
-
This may turn out to be malware instead of an exploit. NSA Said to Exploit Heartbleed Bug for Intelligence for Years (http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html)
The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.
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 (http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html)
-
From Day One i felt there's an underlying story we may never hear...too convienent.
Meanwhile from Day One i thought the "panic" garbage was overblown...and i still do.
-
From Day One i felt there's an underlying story we may never hear...too convienent.
Meanwhile from Day One i thought the "panic" garbage was overblown...and i still do.
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....
-
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 (https://www.ivpn.net/blog/heartbleed-passwords-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 (http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html)
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 (http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html)
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.
-
There's more / Update (http://timesofindia.indiatimes.com/tech/computing/The-Heartbleed-bug-Am-I-at-risk-and-do-I-really-have-to-change-my-password/articleshow/33621019.cms)
-
In my opinion this is nothing but conspirational nonsense.
Most of the story, from day 1, has been conspiratorial.