-
BOTL UPCOMING MAINTENANCE
Hi Everyone, as mentioned in my introduction post, BOTL needs quite a bit of updating, patching and whatever else I might come across. Over the next few weekends BOTL may be unreachable on occasion as I do migrations or updates, etc. Just be patient - we'll be back! I'll generally try to keep these maintenances until later in the evenings.
ssl encryption defeated
- Thread starter andy
- Start date
njstone
BoM January 2010
Great. If the white hats are telling people about it now, you know the others have been using it for a while. The Google and PSN hacks are legendary already, but before that I'm sure it was being used for simple theft.
The way I see it, there is no such thing as total security. If someone wants in bad enough, they'll probably get in. Of course, I do what I can to deter the casual attempts, but that's about all I can do.
The way I see it, there is no such thing as total security. If someone wants in bad enough, they'll probably get in. Of course, I do what I can to deter the casual attempts, but that's about all I can do.
Except that slipping a bit of javascript into one's browser is not as simple as it sounds.
Does anyone know how this actually works? From the little bits of actual detail I can get out of the media reports it looks like they're using a cryptographic weakness to facilitate a Man in the Middle attack?
-Charles
from the article ...
Instead, BEAST carries out what's known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks.
If the attacker's guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.
At the moment, BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their ****** attack to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of Duong and Rizzo's claim that this time can be drastically shortened.
plaintext-recovery attack
Instead, BEAST carries out what's known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks.
If the attacker's guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.
At the moment, BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their ****** attack to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of Duong and Rizzo's claim that this time can be drastically shortened.
plaintext-recovery attack
Alright, so let's walk through the attack. Let's imagine a scenario where the attacker has both access to the cyphertext on the wire, as well as the ability to to inject data into an HTTP stream. It's a bit of a tall order, but theoretically something you can pull off with ARP spoofing, or by compromising a proxy or router somewhere.
How do you leverage that to launch the sort of attack they're describing? JavaScript's same-origin policy will preclude you from generating traffic to arbitrary SSL site to launch the actual attack, so that's a non-starter. You need a way to get the malicious code onto the actual web site you want to steal session credentials for. Since we've already established they're using SSL, I think we have to abandon entire approach.
Perhaps we can try to sneak the code in via a malicious advertisement or some such? That would get your agent into the browser in the appropriate security context, but it does nothing toward getting you access to the cyphertext. In this scenario the difficulty would be in situating yourself such that you could observe the network traffic AND target the user whose traffic you're watching. This is a VERY tall order in most real world scenarios.
It's entirely possible I'm completely missing something important, but it seems like the overwhelming majority of internet users don't need to worry about this.
-Charles
How do you leverage that to launch the sort of attack they're describing? JavaScript's same-origin policy will preclude you from generating traffic to arbitrary SSL site to launch the actual attack, so that's a non-starter. You need a way to get the malicious code onto the actual web site you want to steal session credentials for. Since we've already established they're using SSL, I think we have to abandon entire approach.
Perhaps we can try to sneak the code in via a malicious advertisement or some such? That would get your agent into the browser in the appropriate security context, but it does nothing toward getting you access to the cyphertext. In this scenario the difficulty would be in situating yourself such that you could observe the network traffic AND target the user whose traffic you're watching. This is a VERY tall order in most real world scenarios.
It's entirely possible I'm completely missing something important, but it seems like the overwhelming majority of internet users don't need to worry about this.
-Charles
I did read it, as well as a few other articles on the topic, and frankly I'm still having a hard time imagining how this affects the majority of internet users.
It's not that I don't think the attack is cryptographically valid. I'm just skeptical of an attacker being able to get into position to actually launch it. From the article (emphasis mine):
In post #7 I lay out why this is much easier said than done. It's like saying I can figure out your bank card PIN, all I need is to slip a card into your wallet and tap your phone line. It's a neat trick, but not something I'm worried about.
That said, I'm very curious to see whether they end up releasing some actual exploit code.
-Charles
got it. you're speaking on how close we are to actually seeing this as a widespread attack. i don't think they're quite at your pitch. though, we'd be foolish to think it won't be at some point in the near future. the article doesn't say were seconds away from someone deciphering encrypted data. in fact, the article states it takes about 10 minutes for the "researchers" to decipher an encrypted cookie. but i do believe the article is highlighting that what was once a theoretical weakness in ssl 1.0 is now a proven weakness. the article also suggests that since a multitude of services are using ssl 1.0, that joe internet user may be affected.
Last edited:
This is how encryption goes. We ride one until it gets broken then move on to the next level. There really is a limitless amount of how much encryption you want to put on something, its just the larger you go the more it will cost due to larger data taking more time.
Bingo! There are always new hack and new updates majority of people don't hear about. I listen to securityNow with steve gibbson podcast on the twit network. They discussed this back on April 07, if you want to listen or read the transcript here's the link. It's the last thing disscussed on the show.
SecurityNow Comodo SSL breach
Yeah the way I see it is more of a MITM attack.
But here comes the rub, from what I can gather and know.
In order for someone to state they are PCI compliant (or several other HIPAA, and etc) you have to meet a minimum standard and that standard is SSL 3.0 or TLS 1.0. And that is the standard for the browsers, even if the websites wanted to go to 1.1 or higher to avoid the issue, they can't because not everyone is running the latest and greatest version of a web browser. (If they do they potentially will loose a lot of customers).
That is what is in place now, but in the future who knows.
I am thinking this is more of an issue in an environment where people are connecting using wireless and then sniffing the traffic. Hotels, corporate offices, starbucks, and etc.
Yeah I know, don't ever do critical business on "public" wifi, but it happens, people hook up a phone charger station that is in the middle of major "hackers" conference even if they know it is dangerous (it was), because they "HAD TO HAVE their phone charged":rolling:
But here comes the rub, from what I can gather and know.
In order for someone to state they are PCI compliant (or several other HIPAA, and etc) you have to meet a minimum standard and that standard is SSL 3.0 or TLS 1.0. And that is the standard for the browsers, even if the websites wanted to go to 1.1 or higher to avoid the issue, they can't because not everyone is running the latest and greatest version of a web browser. (If they do they potentially will loose a lot of customers).
That is what is in place now, but in the future who knows.
I am thinking this is more of an issue in an environment where people are connecting using wireless and then sniffing the traffic. Hotels, corporate offices, starbucks, and etc.
Yeah I know, don't ever do critical business on "public" wifi, but it happens, people hook up a phone charger station that is in the middle of major "hackers" conference even if they know it is dangerous (it was), because they "HAD TO HAVE their phone charged":rolling:
Here's a place to start. Charles I think you're close but probably have to be in the middle first, thats how you get your payload to your victim.
Tools needed, Cantenna, laptop, wifi card capable of packet injection, backtrack 5r1 and squid proxy
1. Do a little war driving, find a house using WEP encryption. Crack it. Right now you're down about 15 minutes including drive time. If all that is available is WPA/WPA2 this is going to take longer than 15 minutes lol.
2. Once you're on net run WireShark for a while and see what kind of network traffic you have. If someones home and doing alot of browsing, BINGO.
3. Do a little ARP poisoning or SYN flood to de-auth the computer from the WAP.
4. Once de-authed start your computer accepting connections for the name of the access point. Windows being ohh so helpful will connect to the stronger signal (thank you cantenna).
Now that the persons internet connection is traversing your laptop.
5. Start the squid proxy. This is about the only part that will take some pre-planning in having said mentioned Java exploit put into a usable form and squid set up to replace an advertisement with your tainted java. Something common like a yahoo banner or google add would be a pretty good bet.
6. Start WireShark collecting packets.
What do you think?
Cheers :ccool:
I think arp spoofing or physically inserting yourself into the path of a wired network would have made for a simpler example, but I do like your style.
The part I'm not getting is how you beat the javascript safety features.
Let's say that one way or another you can intercept http requests and insert the javascript payload. Where do you insert it? Let's say you intercept a request for an ad, or some other third party page component. Then what?
I thought javascript code could only issue requests back to the server that served it up. It's a bitch to launch a chosen plaintext crypto attack against anyone when the only place you can issue requests to is a laptop in some guy's car pretending to be akamai.
I believe for the payload to be of any use you'd need to get it into the datastream of the https site you were running the attack against. But then, you know, you'd be trying to insert data into an SSL stream without the session key...
I figure I've got to be missing something, but I'll be damned if I can figure out what it is. Maybe I'm misunderstanding the JavaScript same origin policy?
-Charles
Honestly I'm not a great Java guy. Sounds like you know more than I do. With that said.
It's not just that the person inside is connected to your laptop pretending to be akamai, it's that your laptop is relaying that traffic out to the internet through their own WAP. Thats where squid comes in, its a proxy. So you can do almost anything you want with that data stream. Include fake referring pages, and insert your own code. It sounds like this is alot like cracking WEP. The Java attack keeps requesting an auth so you can collect pieces of it and put it back together or try a new guess at the cypher.
It's a rather viable attack, not super difficult (out of my league for sure though). But the return on invested time to find someone who uses p-yp-l enough to be sitting there when it happens and effort seems low to me.
I guess the biggest point is to realize that you're not 100% safe in your house, so doing anything financial at Fivebucks coffee (which is a much better target for MitM or Cafe Late attacks) should not even be an option. Though I know people still do it.
Cheers :ccool:
It's not just that the person inside is connected to your laptop pretending to be akamai, it's that your laptop is relaying that traffic out to the internet through their own WAP. Thats where squid comes in, its a proxy. So you can do almost anything you want with that data stream. Include fake referring pages, and insert your own code. It sounds like this is alot like cracking WEP. The Java attack keeps requesting an auth so you can collect pieces of it and put it back together or try a new guess at the cypher.
It's a rather viable attack, not super difficult (out of my league for sure though). But the return on invested time to find someone who uses p-yp-l enough to be sitting there when it happens and effort seems low to me.
I guess the biggest point is to realize that you're not 100% safe in your house, so doing anything financial at Fivebucks coffee (which is a much better target for MitM or Cafe Late attacks) should not even be an option. Though I know people still do it.
Cheers :ccool:
Last edited:
Personally I think it's even more scary when something like this happens.
Supposedly a couple of the certs stolen were for M$ and M$ Update. Not to mention several Governments sites.
http://www.infoworld.com/t/cyber-crime/debacle-deepens-hacked-ssl-certificates-issuer-171711
Happy Browsing :ccool:
Supposedly a couple of the certs stolen were for M$ and M$ Update. Not to mention several Governments sites.
http://www.infoworld.com/t/cyber-crime/debacle-deepens-hacked-ssl-certificates-issuer-171711
Happy Browsing :ccool:
I hear what you're saying. My point of confusion is that javascript can only issue direct requests back to the server that served it.
Let's assume you're running this attack against someone's session with ******. Now, let's say we know that ****** uses doubleclick for ads (no idea if that's true, but accept it for this example). So you set your transparent squid proxy to masquerade as ad.doubleclick.net. Now when the victim loads up ****** you can intercept the request for one of the ads on the page (because the victim's browser is really talking to your proxy when it thinks it's talking to ad.doubleclick.net).
The problem is, even if you replace or augment that ad with the javascript payload, that payload can only send requests to ad.doubleclick.net, NOT ******. Now I don't understand the actual attack well enough to know what the BEAST payload actually DOES, but I imagine it would have a hard time participating in a cryptographic attack against a session with ******.com when it isn't actually allowed to send requests to ******.com.
At that point it doesn't matter if ad.doubleclick.net traffic is hitting your proxy, passing through to the internet or being dropped on the floor. Sending requests to ad.doubleclick.net doesn't help you run an attack against the https session the victim has with ******.
My wife and I were up until the wee hours last night talking this through, and the best we could come up with is this:
Javascript served up by ad.doubleclick.net wouldn't be able to directly query ******.com, however, it could insert HTML elements into the DOM that reference ******.com. It's a trick we'd used years ago as part of an XSS attack we ran against a buddy's site, but that's another story.
By inserting HTML elements that reference ******.com you COULD get the victim's browser to issue queries, but it doesn't seem you'd have NEARLY enough control over them to launch an Adaptive Chosen-Plaintext attack. The most we'd ever tried to use the technique for was to smuggle out stolen cookies in IMG tags.
I *really* want to see this exploit when it comes out.
-Charles
Let's assume you're running this attack against someone's session with ******. Now, let's say we know that ****** uses doubleclick for ads (no idea if that's true, but accept it for this example). So you set your transparent squid proxy to masquerade as ad.doubleclick.net. Now when the victim loads up ****** you can intercept the request for one of the ads on the page (because the victim's browser is really talking to your proxy when it thinks it's talking to ad.doubleclick.net).
The problem is, even if you replace or augment that ad with the javascript payload, that payload can only send requests to ad.doubleclick.net, NOT ******. Now I don't understand the actual attack well enough to know what the BEAST payload actually DOES, but I imagine it would have a hard time participating in a cryptographic attack against a session with ******.com when it isn't actually allowed to send requests to ******.com.
At that point it doesn't matter if ad.doubleclick.net traffic is hitting your proxy, passing through to the internet or being dropped on the floor. Sending requests to ad.doubleclick.net doesn't help you run an attack against the https session the victim has with ******.
My wife and I were up until the wee hours last night talking this through, and the best we could come up with is this:
Javascript served up by ad.doubleclick.net wouldn't be able to directly query ******.com, however, it could insert HTML elements into the DOM that reference ******.com. It's a trick we'd used years ago as part of an XSS attack we ran against a buddy's site, but that's another story.
By inserting HTML elements that reference ******.com you COULD get the victim's browser to issue queries, but it doesn't seem you'd have NEARLY enough control over them to launch an Adaptive Chosen-Plaintext attack. The most we'd ever tried to use the technique for was to smuggle out stolen cookies in IMG tags.
I *really* want to see this exploit when it comes out.
-Charles
Agreed. Once you can generate trusted certificates all bets are off. At that point your hypothetical squid proxy can pretend to be anyone, SSL or not.
-Charles
Thats awesome that your girl stayed up with you mulling over this with you. My girl is nerdy, but gets bored quickly when I start talking about these kinds of things.
I get what your saying about Java snuck in under the guise of a doubleclick ad. I think with out really understanding what beast is doing there's really no good way to know for sure.
If you manage to get your hands on it don't forget to share ;D
Cheers :ccool:
I get what your saying about Java snuck in under the guise of a doubleclick ad. I think with out really understanding what beast is doing there's really no good way to know for sure.
If you manage to get your hands on it don't forget to share ;D
Cheers :ccool: