Wow, major https/http hole revealed at blackhat.....

[bsobel]

Say you punch in https...the destination doesn't get encrypted, just the data sent there. When the software sees "https://" come across the line, nothing is stopping it from redirecting you back to "http://". In a classic arp poisoning scheme punching in any url can result in the attacker doing whatever they want. Their machine can respond to the victim any which way it wants.

Your joking right? When the user enters https:// the browser create an encrypted connection to the remote server on (by default) the https port. The MiTM only sees encrypted traffic, it does NOT see 'https://' come across the line... All it sees in that scenario is the IP and port that the broswer attempts to connect to.

Sheesh, do you know anything about this?

 

[bsobel]

Originally posted by: Codewiz
Jesus, if you people would just watch the presentation to the END you would realize this isn't just a https to http replacement. It goes one step FURTHER.

Let me spell it out for you people once again.

The setup.

The tool has a valid wildcard cert for *.jiij.cn
jiij.cn is acting as the router/proxy on the network.

-User goes to http://www.wachovia.com
-User fills in the secure form.
-The tool acting as the router, takes the post and submits it to <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com">https://www.wachovia.com</a></a></a>
-The user is given <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com/ac......dsa&fdsfds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com/accou...ajhfdsa&fdsfds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com/account.aspx?blafhdsakfjdhsajhfdsa&fdsfds.jiij.cn">https://www.wachovia.............ds.jiij.cn</a></a></a> in the URL
-The user browser has a VALID SSL session with the tool because the actual characters /, ?,& are all lookalike characters that are valid in non-top level domains.

-www.wachovia.com/ac......dsa&fdsfds is just a subdomain of jiij.cn

So to the user, it appears that he just authenticated using SSL to the intended site as the SSL cert does match the MITM cert domain.

I (for the record) am not disagree with this. I'm pointing out that a) this is an old attack in the wild for some time b) the user doesnt get an extended validation cert (which doesnt matter in all cases, but DOES in the wachovia example) and c) the user can bypass the attack by starting with https:// everytime (something I know you get, but five40 and our CISSP don't understand)

 

[five40]

Originally posted by: bsobel

Say you punch in https...the destination doesn't get encrypted, just the data sent there. When the software sees "https://" come across the line, nothing is stopping it from redirecting you back to "http://". In a classic arp poisoning scheme punching in any url can result in the attacker doing whatever they want. Their machine can respond to the victim any which way it wants.

Your joking right? When the user enters https:// the browser create an encrypted connection to the remote server on (by default) the https port. The MiTM only sees encrypted traffic, it does NOT see 'https://' come across the line... All it sees in that scenario is the IP and port that the broswer attempts to connect to.

Sheesh, do you know anything about this?

You've never seen something completely take over any address you punch in? Have you ever gone to panera and tried surfing their free internet where it says...hey let me add your mac address first. No matter what you punch in, the little panera internet website comes up.

 

[Codewiz]

Originally posted by: five40

Originally posted by: bsobel

Say you punch in https...the destination doesn't get encrypted, just the data sent there. When the software sees "https://" come across the line, nothing is stopping it from redirecting you back to "http://". In a classic arp poisoning scheme punching in any url can result in the attacker doing whatever they want. Their machine can respond to the victim any which way it wants.

Your joking right? When the user enters https:// the browser create an encrypted connection to the remote server on (by default) the https port. The MiTM only sees encrypted traffic, it does NOT see 'https://' come across the line... All it sees in that scenario is the IP and port that the broswer attempts to connect to.

Sheesh, do you know anything about this?

You've never seen something completely take over any address you punch in? Have you ever gone to panera and tried surfing their free internet where it says...hey let me add your mac address first. No matter what you punch in, the little panera internet website comes up.

That has to do with DNS. Nothing to do with this.

 

[Codewiz]

Originally posted by: bsobel

Originally posted by: Codewiz
Jesus, if you people would just watch the presentation to the END you would realize this isn't just a https to http replacement. It goes one step FURTHER.

Let me spell it out for you people once again.

The setup.

The tool has a valid wildcard cert for *.jiij.cn
jiij.cn is acting as the router/proxy on the network.

-User goes to http://www.wachovia.com
-User fills in the secure form.
-The tool acting as the router, takes the post and submits it to <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com">https://www.wachovia.com</a></a></a></a></a>
-The user is given <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.............ds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.........fdsfds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com/ac......dsa&fdsfds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com/accou...ajhfdsa&fdsfds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com/account.aspx?blafhdsakfjdhsajhfdsa&fdsfds.jiij.cn">https://www.wachovia.............cn</a></a></a></a></a> in the URL
-The user browser has a VALID SSL session with the tool because the actual characters /, ?,& are all lookalike characters that are valid in non-top level domains.

-www.wachovia.com/ac......dsa&fdsfds is just a subdomain of jiij.cn

So to the user, it appears that he just authenticated using SSL to the intended site as the SSL cert does match the MITM cert domain.

I (for the record) am not disagree with this. I'm pointing out that a) this is an old attack in the wild for some time b) the user doesnt get an extended validation cert (which doesnt matter in all cases, but DOES in the wachovia example) and c) the user can bypass the attack by starting with https:// everytime (something I know you get, but five40 and our CISSP don't understand)

Once again, can you provide any documentation that this is an old attack. TheMiddler doesn't count because it did not work for things like SSL links to login pages while still giving the perception that you are logging into the secure site. All it took was looking at the address bar to see it wasn't https. For instance, any site that has a link to their SSL login will get totally owned by this attack. The user will appear to redirect to the SSL site and will be none the wiser.

 

[bsobel]

Once again, can you provide any documentation that this is an old attack. TheMiddler doesn't count because it did not work for things like SSL links to login pages while still giving the perception that you are logging into the secure site. All it took was looking at the address bar to see it wasn't https. For instance, any site that has a link to their SSL login will get totally owned by this attack. The user will appear to redirect to the SSL site and will be none the wiser.

What do you want me to say, I've seen the attack, I've touched the equipment used. I've seen related attacks where malware dropped a fake root cert on the box and then the MiTM did ssl stripping resigned with a cert signed by that root. FSecure did a nice presentation on that at the same conference I was speaking at in Signapore in '07. Sorry if you don't want to believe me, those that know my credentials understand. There really isn't any reason I'd lie about an attack being old. And if you haven't noticed, a few others said the exact same thing...

 

[bsobel]

You've never seen something completely take over any address you punch in? Have you ever gone to panera and tried surfing their free internet where it says...hey let me add your mac address first. No matter what you punch in, the little panera internet website comes up.

:roll: Try it with https traffic, you'll get a cert error.

 

[SagaLore]

Originally posted by: bsobel
CISSP really? Amazing. And how does the broswer reconcile the entered URL with the cert it gets back? While udf encoding and international domains might confuse a user, the browser is not going to see a matching certificate and error.

Guys, this is certificates 101, go read your text books. The fact that you are arguing about this is amazing.

You're bashing my certification based on summaries I'm providing out of an article. I haven't used the tool, so I can't say for certain how the tool works, but I can say for certain how the other author thinks it works. I know you haven't used SSLstrip. I'm pretty sure you haven't used TheMiddler.

I misread the last part, it doesn't use a fake cert, just a mis-leading URL. The author keeps using buzzwords in quotes that are meaning something else. And as far as certificates 101, you can quote RFC's all you want, but we wouldn't have a job if all the binary in the world followed them and nothing could ever be cracked. My strengths aren't in cert-exchange, so thanks for taking the time to point out errors in our logic in a positive and meaningful way.

 

[five40]

Originally posted by: bsobel

Once again, can you provide any documentation that this is an old attack. TheMiddler doesn't count because it did not work for things like SSL links to login pages while still giving the perception that you are logging into the secure site. All it took was looking at the address bar to see it wasn't https. For instance, any site that has a link to their SSL login will get totally owned by this attack. The user will appear to redirect to the SSL site and will be none the wiser.

What do you want me to say, I've seen the attack, I've touched the equipment used. Sorry if you don't want to believe me, those that know my credentials understand. There really isn't any reason I'd lie about an attack being old. And if you haven't noticed, a few others said the exact same thing...

While we might not agree on being able to redirect from https to http...bsobel is right in that this isn't anything new. He's added some new fresh ideas into the mix, but the basic concept is nothing new.

 

[bsobel]

You're bashing my certification based on summaries I'm providing out of an article.

Im bashing your cert based on you believing what you read in an article after you've had actual education in the area and couldn't realize which parts what was right and what was wrong. You then rewrote the article in an even more error prone way. When told you were wrong, you then simply argued without reconsidering the information you were given.

I misread the last part, it doesn't use a fake cert, just a mis-leading URL.

Actually it does, a cert for that misleading url.

 

[bsobel]

While we might not agree on being able to redirect from https to http...bsobel is right in that this isn't anything new. He's added some new fresh ideas into the mix, but the basic concept is nothing new.

Hold on, we were discussing redirecting from http to https, the step needed to start the attack. Of course the server can redirect from https to http. But how would you get the wachovia server to do that for you since your not in the middle when the traffic is encrypted...

 

[DisgruntledVirus]

TEH INTERNETS IZ SRS BUSINESS GAIS

 

[SagaLore]

Originally posted by: bsobel
Your joking right? When the user enters https:// the browser create an encrypted connection to the remote server on (by default) the https port. The MiTM only sees encrypted traffic, it does NOT see 'https://' come across the line... All it sees in that scenario is the IP and port that the broswer attempts to connect to.

Sheesh, do you know anything about this?

Right, it sees the tcp handshake on port 443, followed by the key exchange to establish ssl. What if it hijacks the session before the key exchange starts? Ah okay, I see - https://www.anandtech.com:80/ is failing.

I need to dig more into this.

 

[five40]

Originally posted by: bsobel

While we might not agree on being able to redirect from https to http...bsobel is right in that this isn't anything new. He's added some new fresh ideas into the mix, but the basic concept is nothing new.

Hold on, we were discussing redirecting from http to https, the step needed to start the attack. Of course the server can redirect from https to http. But how would you get the wachovia server to do that for you since your not in the middle when the traffic is encrypted...

bla my brain farted...

 

[fishjie]

Very interesting discussion. Can anyone recommend me a good tutorial about certs? I'd like to learn more.

 

[randay]

oh.

 

[bsobel]

Right, it sees the tcp handshake on port 443, followed by the key exchange to establish ssl. What if it hijacks the session before the key exchange starts? Ah okay, I see - <a target=_blank class=ftalternatingbarlinklarge href="https://www.anandtech.com:80/">https://www.anandtech.com:80/</a> is failing.

And how did you expect https:// on the http:// port not to fail?

 

[spidey07]

Originally posted by: fishjie
Very interesting discussion. Can anyone recommend me a good tutorial about certs? I'd like to learn more.

Read the RFC for Secure Sockets Layer? Otherwise there are plenty of books on the subject.

http://tools.ietf.org/html/rfc5246

Otherwise the wikipedia is pretty decent and can get you started.

http://en.wikipedia.org/wiki/Transport_Layer_Security

 

[fishjie]

Yeah RFCs go into a really deep low level look at things. I just want something more high level. I'd only ever read an RFC if I had to implement something based on it.

 

[spidey07]

Originally posted by: fishjie
Yeah RFCs go into a really deep low level look at things. I just want something more high level. I'd only ever read an RFC if I had to implement something based on it.

But that's the only way you'll ever really understand it IMHO. That and looking at packet captures, you can read SSL, just not it's payload.

 

[zinfamous]

Originally posted by: mxyzptlk
Whatever idiot tries to steal my identity deserves the crushing load of debt he or she then stands to inherit.

:laugh:

so does this mean that my porn accounts are no longer safe?????

 

[SagaLore]

Originally posted by: bsobel
When told you were wrong, you then simply argued without reconsidering the information you were given.

It took you about a page worth of posts before you actually provided any information. Most of the thread wouldn't exist if you didn't come across so callous.

 

[Red Squirrel]

Wow this is very scary. I have not watched the video yet but I'll be sure to check it out when I get home. I knew it was a matter of time until SSL is cracked.

 

[bsobel]

Originally posted by: RedSquirrel
Wow this is very scary. I have not watched the video yet but I'll be sure to check it out when I get home. I knew it was a matter of time until SSL is cracked.

SSL is not cracked :roll:

 

[SagaLore]

Originally posted by: bsobel

Right, it sees the tcp handshake on port 443, followed by the key exchange to establish ssl. What if it hijacks the session before the key exchange starts? Ah okay, I see - <a target=_blank class=ftalternatingbarlinklarge href="https://www.anandtech.com:80/"><a target=_blank class=ftalternatingbarlinklarge href="https://www.anandtech.com:80/">https://www.anandtech.com:80/</a></a> is failing.

And how did you expect https:// on the http:// port not to fail?

For the same reason that http:// on port 443 or any other port doesn't fail. I didn't know if the browser would enforce the key exchange with https in the URL, since the server actually starts the key exchange.