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

[Codewiz]

Originally posted by: bsobel

If it has existed in the wild, I just want to see some references.

The closest public reference I can give you is the middler reference I talked about before. You can also google for sslstripping it should be pretty obvious.

I read themiddler information. This tool goes further in the browser tricks using the valid ssl cert to a domain that it will match using IDN-valid characters that look like the normal characters we use.

 

[Codewiz]

Originally posted by: SagaLore

Originally posted by: Crusty

Originally posted by: bsobel

SSH uses SSL. The weakness is in SSL, not https or ssh.

Actually this is a weakness in https much more than SSL itself. It relies on seeing the plaintext traffic and stripping out ssl links (or directing the user to a different domain on SSL for which the attacker got a cert). Its not a break of SSL itself at all.

Yeah, the article I read didn't make a note of the fact that you need the plaintext traffic first. I thought it was just like the exploit that the MD5 collisions would allow. Either way, publicly broadcast wifi = bad news for personal information.

Only going by the article, here is what happens:

* Watches traffic
* When it sees HTTPS, it substitutes it with HTTP
* Tells the server that an encrypted page has been sent
* Adds padlock icon to URL

So the server actually doesn't know you're on http, so it won't redirect you? Its funny that the padlock icon is what really is getting everyone.

Actually it goes further than that. The last exploit was creating domains using IDN-valid characters and a valid wildcard cert on non-top level domains.

This bypasses the browser warnings about certs. It will appear like a valid SSL connection with the intended site.

 

[bsobel]

The cert will match the entered URL.

No it wont. its compared right to left...

 

[bsobel]

* Watches traffic
* When it sees HTTPS, it substitutes it with HTTP
* Tells the server that an encrypted page has been sent
* Adds padlock icon to URL

So the server actually doesn't know you're on http, so it won't redirect you? Its funny that the padlock icon is what really is getting everyone.

The server doesn't care your on http, thats the issue. If the major banks turned off dishing up the http pages for all pages that needed to be secure, this attack goes away as well. Not sure what you meant by 'tells the server an encrypted page has been sent' or 'adds a padlock icon to the url'.

 

[bsobel]

Actually it goes further than that. The last exploit was creating domains using IDN-valid characters and a valid wildcard cert on non-top level domains.

Which requires the first redirect to still be done as HTTP or the browser complains about the HTTPS redirection with a cert warning.

It will appear like a valid SSL connection with the intended site.

SSL yes, extended validaition certs, no.

 

[Codewiz]

Originally posted by: bsobel

The cert will match the entered URL.

No it wont. its compared right to left...

Seriously....

Yes it will.

It uses IDN-valid characters to replace the &, ?, and / on non top level domains.

so they create a cert for *.jiij.cn

anything ending with jiij.cn will be valid and match correct?

so they now create links that look like this.

https://login.yahoo.com/login.aspx?...ashjkdsafhjkdsafdshfdhjksfdhjskafhjds.jiij.cn

now the / and the ? are not the normal characters.

The whole login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds

is a valid subdomain of jiij.cn and will validate with the valid *.jiij.cn cert

 

[SagaLore]

Originally posted by: bsobel

* Watches traffic
* When it sees HTTPS, it substitutes it with HTTP
* Tells the server that an encrypted page has been sent
* Adds padlock icon to URL

So the server actually doesn't know you're on http, so it won't redirect you? Its funny that the padlock icon is what really is getting everyone.

The server doesn't care your on http, thats the issue. If the major banks turned off dishing up the http pages for all pages that needed to be secure, this attack goes away as well. Not sure what you meant by 'tells the server an encrypted page has been sent' or 'adds a padlock icon to the url'.

Its directly from the article:

Marlinspike's SSLstrip sits on a local network and intercepts traffic. When it detects an encrypted HTTPS (Hypertext Transfer Protocol Secure) site, it automatically substitutes a look-alike of the intended destination as an unencrypted HTTP site. That switching trick strips away the security that prevents a third party from stealing or modifying data, while telling the server that an encrypted page has been sent.

To better impersonate the security measures some users have come to expect, "SSLstrip" even adds a padlock icon that appears beside the URL, offering users a false sense that they can safely input secure information.

 

[five40]

Originally posted by: bsobel

Originally posted by: five40

Originally posted by: Codewiz

Originally posted by: bsobel
From Information Week:

"Marlinspike's attack isn't so much technical as it is social engineering. It relies on users failing to recognize the distinction between HTTP and HTTPS sessions and on other insecure habits, like people's penchant for typing, say, "www.wellsfargo.com" without the HTTPS portion of the URL."

Correct, if everyone typed in https for every bank website, then the attack is useless. But that is not what people do.

punching in https doesn't stop the attack when the domain trick is used

Actually it does, since the MiTM has to redirect the user to wildcarded domain name. The browser will complain since the cert won't match the entered URL.

Why would the browser complain? The URL would match the cert. It matches the cert of the registered domain. It can do any 302 it wants.

 

[SagaLore]

Originally posted by: Codewiz

Originally posted by: bsobel

The cert will match the entered URL.

No it wont. its compared right to left...

Seriously....

Yes it will.

It uses IDN-valid characters to replace the &, ?, and / on non top level domains.

so they create a cert for *.jiij.cn

anything ending with jiij.cn will be valid and match correct?

so they now create links that look like this.

<a target=_blank class=ftalternatingbarlinklarge href="https://login.yahoo.com/login....ksfdhjskafhjds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds.jiij.cn">https://login.yahoo.com/.........afhjds.jiij.cn</a></a>

now the / and the ? are not the normal characters.

The whole login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds

is a valid subdomain of jiij.cn and will validate with the valid *.jiij.cn cert

Codewiz is talking about this part of the article:

In his talk, Marlinspike also displayed a method for making the ruse even less detectable. By hosting the substituted fraud site at an arbitrary HTTPS address and adding a look-alike series of characters to the front of the URL, a user's browser can be tricked into showing all the signs of an HTTPS site.

Marlinspike showed, for instance, how the character /, which appears in many Web addresses, can be substituted with an identical character that allows a data thief to substitute his or her own "secure" site. The only sign of the fraud would be the false domain, like "ijjk.cn," that appears at the end of the address--usually too far to the right to even appear in the browser's URL bar.

Its your typical MiTM attack combined with your typical Phishing scam. :shocked:

 

[bsobel]

Originally posted by: Codewiz

Originally posted by: bsobel

The cert will match the entered URL.

No it wont. its compared right to left...

Seriously....

Yes it will.

It uses IDN-valid characters to replace the &, ?, and / on non top level domains.

so they create a cert for *.jiij.cn

anything ending with jiij.cn will be valid and match correct?

so they now create links that look like this.
xxxx<a target=_blank class=ftalternatingbarlinklarge href="https://login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds.jiij.cn">https://login.yahoo.com/log......hjskafhjds.jiij.cn</a>

now the / and the ? are not the normal characters.

The whole login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds

is a valid subdomain of jiij.cn and will validate with the valid *.jiij.cn cert

Seriously, it wont. If the user types in https://www.wachovia.com it's NOT going to match a cert for www.wachovia.com.jiij.cn If the user enters www.wachovia.com the attack has to first redirect the user to http://www.wachovia.com.jiij.cn Then, and only then, can they redirect to https://www.wachovia.com.jiij.cn

 

[bsobel]

Why would the browser complain? The URL would match the cert. It matches the cert of the registered domain. It can do any 302 it wants.

It will NOT match the cert. www.wachovia.com DOES NOT MATACH *.jiij.cn. The have to get the user to www.wachovia.com.jiij.cn first. That requires an initial redirect in http mode, https mode will complain.

 

[Codewiz]

Originally posted by: bsobel

Originally posted by: Codewiz

Originally posted by: bsobel

The cert will match the entered URL.

No it wont. its compared right to left...

Seriously....

Yes it will.

It uses IDN-valid characters to replace the &, ?, and / on non top level domains.

so they create a cert for *.jiij.cn

anything ending with jiij.cn will be valid and match correct?

so they now create links that look like this.
xxxx<a target=_blank class=ftalternatingbarlinklarge href="https://login.yahoo.com/log......hjskafhjds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://login.yahoo.com/login....ksfdhjskafhjds.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds.jiij.cn">https://login.yahoo.c............ds.jiij.cn</a></a></a>

now the / and the ? are not the normal characters.

The whole login.yahoo.com/login.aspx?fdsfjkdsafdsahfdshjkafhjkdsahfdjshfashjkdsafhjkdsafdshfdhjksfdhjskafhjds

is a valid subdomain of jiij.cn and will validate with the valid *.jiij.cn cert

Seriously, it wont. If the user types in <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> it's NOT going to match a cert for www.wachovia.com.jiij.cn If the user enters www.wachovia.com the attack has to first redirect the user to http://www.wachovia.com.jiij.cn Then, and only then, can they redirect to <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn">https://www.wachovia.com.jiij.cn</a></a>

Never did I say if htey type <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com">https://www.wachovia.com</a>

This is all predicated by them going to http://www.wachovia.com

And EXPECTING to see a lock and https when they log in.

 

[Codewiz]

Originally posted by: bsobel

Why would the browser complain? The URL would match the cert. It matches the cert of the registered domain. It can do any 302 it wants.

It will NOT match the cert. www.wachovia.com DOES NOT MATACH *.jiij.cn. The have to get the user to www.wachovia.com.jiij.cn first. That requires an initial redirect in http mode, https mode will complain.

Once again if you would WATCH the presentation, you would know what I am referring to and the setup.

 

[five40]

Originally posted by: bsobel

Why would the browser complain? The URL would match the cert. It matches the cert of the registered domain. It can do any 302 it wants.

It will NOT match the cert. www.wachovia.com DOES NOT MATACH *.jiij.cn. The have to get the user to www.wachovia.com.jiij.cn first. That requires an initial redirect in http mode, https mode will complain.

Ummm...the program completely controls the flow of traffic. You can send whatever request in the browser to any secure site, the software then says.."hey the response from the server is...goto https://*jiij.cn". The browser throws 0 complaints.

 

[bsobel]

Never did I say if htey type <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>
This is all predicated by them going to http://www.wachovia.com
And EXPECTING to see a lock and https when they log in.

Yes you did:

Originally posted by: Codewiz

Originally posted by: bsobel

Originally posted by: five40

Originally posted by: Codewiz

Originally posted by: bsobel
From Information Week:

"Marlinspike's attack isn't so much technical as it is social engineering. It relies on users failing to recognize the distinction between HTTP and HTTPS sessions and on other insecure habits, like people's penchant for typing, say, "www.wellsfargo.com" without the HTTPS portion of the URL."

Correct, if everyone typed in https for every bank website, then the attack is useless. But that is not what people do.

punching in https doesn't stop the attack when the domain trick is used

Actually it does, since the MiTM has to redirect the user to wildcarded domain name. The browser will complain since the cert won't match the entered URL.

The cert will match the entered URL.

five40 said that punching in https doesnt stop the attack. I said it does, and you then claimed the cert would match.

 

[SagaLore]

Originally posted by: bsobel
Seriously, it wont. If the user types in <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> it's NOT going to match a cert for www.wachovia.com.jiij.cn If the user enters www.wachovia.com the attack has to first redirect the user to http://www.wachovia.com.jiij.cn Then, and only then, can they redirect to <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn">https://www.wachovia.com.jiij.cn</a></a>

Based on what the article is saying, SSLstrip does not have to wait for the user to visit the http site first. If they type in https://somesite, it will stop that request and generate its own http request, while pretending to still be https. The bogus https will have a cert for its own domain, which impersonates the real domain by using non-standard characters.

Use a / (fraction slash) instead of / (forward slash).

 

[bsobel]

Ummm...the program completely controls the flow of traffic. You can send whatever request in the browser to any secure site, the software then says.."hey the response from the server is...goto https://*jiij.cn". The browser throws 0 complaints.

Your confused. You enter https://www.wachovia.com in your browser You connect to what you think is that address but its the man in the middle who then tries to give you back a response and cert for www.wachovia.com.jiij.cn. The browser WILL complain about that cert. That is before the MiTM can give you a 302, it can't except the response if its not connected to the right server to begin with.

Thats why the attack MUST start with http...

 

[bsobel]

Originally posted by: SagaLore

Originally posted by: bsobel
Seriously, it wont. If the user types in <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> it's NOT going to match a cert for www.wachovia.com.jiij.cn If the user enters www.wachovia.com the attack has to first redirect the user to http://www.wachovia.com.jiij.cn Then, and only then, can they redirect to <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com.jiij.cn">https://www.wachovia.com.jiij.cn</a></a></a></a>

Based on what the article is saying, SSLstrip does not have to wait for the user to visit the http site first. If they type in https://somesite, it will stop that request and generate its own http request, while pretending to still be https. The bogus https will have a cert for its own domain, which impersonates the real domain by using non-standard characters.

Use a / (fraction slash) instead of / (forward slash).

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.

 

[Codewiz]

Originally posted by: bsobel

Never did I say if htey type <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>
This is all predicated by them going to http://www.wachovia.com
And EXPECTING to see a lock and https when they log in.

Yes you did:

Originally posted by: Codewiz

Originally posted by: bsobel

Originally posted by: five40

Originally posted by: Codewiz

Originally posted by: bsobel
From Information Week:

"Marlinspike's attack isn't so much technical as it is social engineering. It relies on users failing to recognize the distinction between HTTP and HTTPS sessions and on other insecure habits, like people's penchant for typing, say, "www.wellsfargo.com" without the HTTPS portion of the URL."

Correct, if everyone typed in https for every bank website, then the attack is useless. But that is not what people do.

punching in https doesn't stop the attack when the domain trick is used

Actually it does, since the MiTM has to redirect the user to wildcarded domain name. The browser will complain since the cert won't match the entered URL.

The cert will match the entered URL.

five40 said that punching in https doesnt stop the attack. I said it does, and you then claimed the cert would match.

Sorry I didn't spell it out to you. I AGREED typing https from the beginning NULLIFIES the attack. My second statement in CONTEXT OF THE ATTACK, it will match. Sorry you can't get that.

It is the only way to read it because if you do https from the start there is no attack so there is no cert to match as their is NO ATTACK. So if there is no attack how could my comment about the cert matching make sense EXCEPT in the context of the attack.

 

[five40]

Originally posted by: bsobel

Ummm...the program completely controls the flow of traffic. You can send whatever request in the browser to any secure site, the software then says.."hey the response from the server is...goto https://*jiij.cn". The browser throws 0 complaints.

Your confused. You enter <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com">https://www.wachovia.com</a> in your browser You connect to what you think is that address but its the man in the middle who then tries to give you back a response and cert for www.wachovia.com.jiij.cn. The browser WILL complain about that cert. That is before the MiTM can give you a 302, it can't except the response if its not connected to the right server to begin with.

Thats why the attack MUST start with http...

No I am not confused...you are confused. The attack uses a redirect. You don't stay at wachovia...you go to a url looking exactly like wachovia. Ugghhh. And do you really work for symantic or some av firm? Did you even watch the presentation?

 

[bsobel]

It is the only way to read it because if you do https from the start there is no attack so there is no cert to match as their is NO ATTACK. So if there is no attack how could my comment about the cert matching make sense EXCEPT in the context of the attack.

Well, the other post didn't understand that and you posted your correct as a comment to me, not to him. And, if you haven't noticed, there are others in the thread you think that the browser doesn't compare certs when accepting traffic form a server

 

[spidey07]

bsobel is right guys, all it is doing is taking the https links in the page sent to the client and replacing them with http. This technique has been around for a while. The only "padlock" it gets is the URL icon, NOT an ssl padlock. This approach is very easy to steal login information because you, as a user, supply it and assume it's secure.

When it's not. You're sending http to the MITM clear text over HTTP. The MITM then proxies this to the real HTTPS site.

 

[bsobel]

No I am not confused...you are confused. The attack uses a redirect. You don't stay at wachovia...you go to a url looking exactly like wachovia. Ugghhh. And do you really work for symantic or some av firm? Did you even watch the presentation?

Yes, the first redirect has to happen in HTTP mode since the MiTM CANT SEE THE SSL TRAFFIC other than for the domains IT DISHES UP. So the first step MUST BE http. Go watch it again.

Now if you got the link in a phishing email and its a bogus https link using udf encoding, sure. But we are discussing a user walking into starbucks and type www.wachovia.com into their browser. If they enter https://www.wachovia.com the attacker NEVER gets a chance to play, if they enter http://www.wachovia.com they do.

 

[five40]

Originally posted by: bsobel

No I am not confused...you are confused. The attack uses a redirect. You don't stay at wachovia...you go to a url looking exactly like wachovia. Ugghhh. And do you really work for symantic or some av firm? Did you even watch the presentation?

Yes, the first redirect has to happen in HTTP mode since the MiTM CANT SEE THE SSL TRAFFIC other than for the domains IT DISHES UP. So the first step MUST BE http. Go watch it again.

Now if you got the link in a phishing email and its a bogus https link using udf encoding, sure. But we are discussing a user walking into starbucks and type www.wachovia.com into their browser. If they enter <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com">https://www.wachovia.com</a> the attacker NEVER gets a chance to play, if they enter http://www.wachovia.com they do.

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.

 

[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">https://www.wachovia.com</a></a>
-The user is given <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.com.........fdsfds.jiij.cn</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.