World takes notice as SSL-chewing BEAST is unleashed With the decrypting of a protected PayPal browser cookie at a security conference Friday, it became official: the internet's foundation of trust has suffered yet another serious fracture that will require the attention of the industry's best minds. Within hours of the demonstration by researchers Juliano Rizzo and Thai Duong, …
That tool is no different to any other - it basically generates certificates on-the-fly and acts as man-in-the-middle.
If you ARE stupid enough to trust random certificates (and your browser will throw a fit unless your network admin has inserted the cain CA into their "trusted CA" list) for a secure connection, then yes, cain can "already" do this.
But in terms of stealing data? This is about breaking the stream, not acting as a TRUSTED man-in-the-middle. Deploy cain on a network, you break everyone's browsers on HTTPS sites and the admins start poking. Deploy this on a network (which allows Javascript through unhindered), get enough people to visit HTTPS sites while it's there (and injecting its Javascript into NON-SECURE pages to help it decrypt the secure ones) and you *may* be able to silently sniff all HTTPS communications and decrypt them in a reasonable amount of time without ANYONE noticing.
SSL-interception was, and still is, believed to be impossible when the software and admin does what they should. BEAST is a known-plaintext attack that significantly reduces the time to decrypt a stream you've recorded every byte of if you let it inject plaintext of its choosing into the conversation. Cain in a main-in-the-middle attack that relies on people trusting falsified (and obviously so) SSL certificates for any site they visit, signed only by a "fake" CA that any browser in the world would reject by default. Two totally different things. Neither are that scary when you use the correct protocols, correctly, from a decent security-aware code (OpenSSL has already been fixed against BEAST for 9 years - it's the others that didn't bother).
This is a more theoretical than practical attack I think. After all, if you can overcome the SOP, you can simply read the decrypted cookie straight out of the browser's DOM for the page in question, without all that tedious mucking about in SSL.
"a patch introduced by OpenSSL in 2002 to fix this very vulnerability was turned off because it introduced incompatibilities in software from Microsoft."
"This vuln should have been closed 9 years ago but wasn't because M$ couldn't fix their shit"?
Really????? Not that I'm surprised, mind you, but a public apology from Microsoft would still be nice, just because they'd hate to have to make it.
"Really????? Not that I'm surprised, mind you, but a public apology from Microsoft would still be nice, "
No, better still just send them the bill for fixing it.
If MS had to pay damages for their defects, one of two things would happen
A) Their code would become secure
B) They would be out of business, and replaced by a company offering a secure OS
Software is the only industry where issuing a defective product is considered normal business practice by the major players
Balls balls balls. There are HEAPS of industries where the cost of fixing a defective product before it hits the market is deemed lower than the cost to rectify it later. Motor cars for a start, but also mobile phones (and mobilephone networks...) buildings, toys, furniture, food at restaurants, banks (toxic loans bundles anyone?), the Tube, etc etc etc. Oh, and don't forget all manner of computer hardware as well. It's complete and utter nonsense to suggest that Software is the only industry to do this.
What they do is to ascertain the impact of the defect(s), the cost of the fix, and the likelihood it will be an issue. From there's it's all economics I'm afraid.
Meanwhile, I applaud you for your choice of flawless OS. Which one is it, by the way, I would love to have an OS with absolutley no defects at all. I look forward to your enlightening response.
Quote stolen from OpenVPN list:
From: James Yonan
Organisation: OpenVPN Technologies, Inc.
...
One of the common workarounds for this vulnerability is to have the SSL
implementation add empty fragments into the application data stream.
OpenSSL has implemented this workaround since 0.9.6d (9 May 2002).
...
Now if OpenSSL patched this back in 2002, you might be wondering why
it's an exploitable vulnerability today. I think the answer is that
while OpenSSL patched the vulnerability, NSS did not (NSS is an
alternative to OpenSSL that is widely used in web browsers).
In fact, if you look at this recent commit to NSS by the Chromium
project (presumably to address the BEAST exploit), you see the same
workaround being added to NSS that was added to OpenSSL 9 years ago.
...
Since TLS 1.1 was ratified in 2006 there has been added protection against Cypher Block Chaining attacks which apparently means that later versions are not vulnerable to this exploit.
It seems crazy that so many "secure" web sites are still using a standard that was superseded over five years ago because a known vulnerability needed to be fixed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
