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

[SagaLore]

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.

Try these (pictures )

http://technet.microsoft.com/e.../library/cc785811.aspx

https://www.securetrust.com/resources/how-ssl-works

 

[bsobel]

since the server actually starts the key exchange.

Wrong again, the client does. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client.

 

[rudeguy]

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. 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...

Just out of curiosity, what kind of credentials do you have that you were speaking on this subject in Singapore?

 

[SagaLore]

Originally posted by: bsobel

since the server actually starts the key exchange.

Wrong again, the client does. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client.

Right right, but I'm talking further down - the part that starts the encryption.

 

[bsobel]

Just out of curiosity, what kind of credentials do you have that you were speaking on this subject in Singapore?

I'm the chief software architect at Symantec currently responsible for the endpoint security products.

 

[Legendary]

As long as it's just the stupid and inattentive being affected, I think I'm OK with it.

Good to see mathematical factoring hasn't gotten to the point of breaking RSA.

 

[spidey07]

Originally posted by: SagaLore

Originally posted by: bsobel

since the server actually starts the key exchange.

Wrong again, the client does. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client.

Right right, but I'm talking further down - the part that starts the encryption.

WHAT!???

bsobel described the zero state start of SSL. What are you talking about? Further down from what?

 

[SagaLore]

Originally posted by: spidey07

Originally posted by: SagaLore

Originally posted by: bsobel

since the server actually starts the key exchange.

Wrong again, the client does. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client.

Right right, but I'm talking further down - the part that starts the encryption.

WHAT!???

bsobel described the zero state start of SSL. What are you talking about? Further down from what?

http://support.microsoft.com/kb/257591

1. Client sends the server client's ssl version #, cipher settings, other info
2a. Server sends the client the server's ssl version #, cipher settings, other info
2b. Server sends its own certificate
3. Client authenticates server
4. Client creates pre-master secret, encrypts it with server's public key from the cert, sends to server
5. Server's optional client authentication
6. more optional stuff
7. Both the client and server use master secret to generate symmetric session keys
8. Client tells the server, hey, I'm ready to go, going forward we're encrypted, and that the handshake is finished
9. Server says ditto
10. Session begins

The "key exchange" I was referring to was steps 2b-4, and not the entire SSL handshake.

I see unencrypted tcp 443 traffic all the time. I was wondering if the browser would ignore the lack of response from the initial hello if it connected to port 80 instead.

 

[ViviTheMage]

uhohs

 

[bsobel]

I see unencrypted tcp 443 traffic all the time. I was wondering if the browser would ignore the lack of response from the initial hello if it connected to port 80 instead.

If you actually knew anything about this, you wouldn't have to wonder.

 

[SagaLore]

Fired up wireshark... lets see what we got here...

Here is a screenshot of an ssl handshake, followed by the initial page load. The only thing you can get out of the packets is the initial domain that I visit, which is in the "Client Hello".

So anyway, I think I properly understand this now. This is what we know about SSLstrip:

* Sits on local network and intercepts traffic. (part we don't know is how? trojan? proxy?)
* It looks for HTTPS (redirect from the server, from HTTP page?)
* On client side, they are given HTTP (we assume with redirect?)
* SSLstrip completes the ssl handshake as the MiTM, and is now proxying the session

Right?

 

[Red Squirrel]

Originally posted by: SagaLore
Fired up wireshark... lets see what we got here...

Here is a screenshot of an ssl handshake, followed by the initial page load. The only thing you can get out of the packets is the initial domain that I visit, which is in the "Client Hello".

So anyway, I think I properly understand this now. This is what we know about SSLstrip:

* Sits on local network and intercepts traffic. (part we don't know is how? trojan? proxy?)
* It looks for HTTPS (redirect from the server, from HTTP page?)
* On client side, they are given HTTP (we assume with redirect?)
* SSLstrip completes the ssl handshake as the MiTM, and is now proxying the session

Right?

That part that scares me is in the guy's test, it actually sat on his own web server, and he got people's email accounts, credit cards and paypal passwords. Even with arp poisoning, how can you intercept INTERNET traffic? Unless his server happens to be on the same switch as some of those web servers, I'm really wondering how he managed to intercept traffic not even going to his web server.

Maybe the movie explains more, but I was unable to open it. Just crashed.

 

[FP]

Originally posted by: RedSquirrel

Originally posted by: SagaLore
Fired up wireshark... lets see what we got here...

Here is a screenshot of an ssl handshake, followed by the initial page load. The only thing you can get out of the packets is the initial domain that I visit, which is in the "Client Hello".

So anyway, I think I properly understand this now. This is what we know about SSLstrip:

* Sits on local network and intercepts traffic. (part we don't know is how? trojan? proxy?)
* It looks for HTTPS (redirect from the server, from HTTP page?)
* On client side, they are given HTTP (we assume with redirect?)
* SSLstrip completes the ssl handshake as the MiTM, and is now proxying the session

Right?

That part that scares me is in the guy's test, it actually sat on his own web server, and he got people's email accounts, credit cards and paypal passwords. Even with arp poisoning, how can you intercept INTERNET traffic? Unless his server happens to be on the same switch as some of those web servers, I'm really wondering how he managed to intercept traffic not even going to his web server.

Maybe the movie explains more, but I was unable to open it. Just crashed.

Tor

He was routing other Tor client's "anonymous" traffic through his network.

 

[FP]

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"><a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.com">https://www.wachovia.com</a></a></a></a></a></a>
-The user is given <a target=_blank class=ftalternatingbarlinklarge href="https://www.wachovia.............iij.cn"><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.............a></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)

I thought even this wasn't fool-proof because he was able to create/sign his own certs for the requested site on the fly (exploiting a Basic Constraints hole with sslsniff) and then seamlessly act as the middleman.

 

[bsobel]

I thought even this wasn't fool-proof because he was able to create/sign his own certs for the requested site on the fly (exploiting a Basic Constraints hole with sslsniff) and then seamlessly act as the middleman.

Nope, the initial setup won't happen. The jump point has to be an http connection.

 

[ivan2]

Originally posted by: SagaLore
Fired up wireshark... lets see what we got here...

Here is a screenshot of an ssl handshake, followed by the initial page load. The only thing you can get out of the packets is the initial domain that I visit, which is in the "Client Hello".

So anyway, I think I properly understand this now. This is what we know about SSLstrip:

* Sits on local network and intercepts traffic. (part we don't know is how? trojan? proxy?)
* It looks for HTTPS (redirect from the server, from HTTP page?)
* On client side, they are given HTTP (we assume with redirect?)
* SSLstrip completes the ssl handshake as the MiTM, and is now proxying the session

Right?

i think this part is what causes confusion. it looks for http and redirects to an https phishing site.

regarding 1st, free wifi =D

am i right?

 

[hanoverphist]

sooo... help a no0b out here... where does the attack generate from? your wireless connection, as in someone sitting there with an AP and giving out free service? or is this some kind of attack that can be done on the net, as in from the hackers moms basement? do i have to worry about this on my home wireless network, or is it just ones out in the real world that i cant guarantee?

 

[SagaLore]

Here we go. FYI, bsobel was 100% correct from the start. Here is how SSLstrip works:

# Does an MITM on the HTTP connection
# Replaces all the HTTPS links with HTTP ones but remembers the links which were changed
# Communicates with the victim client on an HTTP connection for any secure link
# Communicates with the legitimate server over HTTPS for the same secure link
# Communication is transparently proxied between the victim client and the legitimate server
# Images such as the favicon are replaced by images of the familiar "secure lock" icon, to build trust
# As the MITM is taking places all passwords, credentials etc are stolen without the Client knowing

source: http://www.securitytube.net/De...e-Blackhat)-video.aspx

The site visit has to start off with an HTTP visit first.

 

[Codewiz]

Originally posted by: SagaLore
Here we go. FYI, bsobel was 100% correct from the start. Here is how SSLstrip works:

# Does an MITM on the HTTP connection
# Replaces all the HTTPS links with HTTP ones but remembers the links which were changed
# Communicates with the victim client on an HTTP connection for any secure link
# Communicates with the legitimate server over HTTPS for the same secure link
# Communication is transparently proxied between the victim client and the legitimate server
# Images such as the favicon are replaced by images of the familiar "secure lock" icon, to build trust
# As the MITM is taking places all passwords, credentials etc are stolen without the Client knowing

source: http://www.securitytube.net/De...e-Blackhat)-video.aspx

The site visit has to start off with an HTTP visit first.

I swear no one watched his presentation to the end.

Like I have stated. It does more than that. That is what it does prior to his inclusion of the lookalike characters and non-top level domain trick.

Basically instead of using the favicon, he creates this SSL connection using a valid certificate and builds links that look almost identical to the original links.

So the connection between the user and SSLstrip is HTTPS and SSLstrip has an SSL connection with the website.

The user will be fooled UNLESS he look at the end of the domain and/or looks at the actual cert.

 

[FelixDeCat]

Now I know why I stuck to finance and avoided IT. Its safe to say I have no idea whats going on here, but Im learning!

 

[bsobel]

The user will be fooled UNLESS he look at the end of the domain and/or looks at the actual cert.

Yep, or unless they notice the cert is the wrong type (e.g. not ev FI cert...)

 

[Goosemaster]

Why is this so hard for people to understand?

It intercepts, rewrites urls, sets up a valid ssl connection between the client and the proxy,
then proceeds to proxy all requests over a legit ssl connection on the other end while maintaining a pretty url for the client the entire time.

vpn to a secure proxy or ssl-ev ftw.

bsobel:

seriously, wTF is up with everything prior to MR3-MR4.... MAD levels of anger your way for that...:|

MR4 is okay I guess (perf. scores are much improved).

 

[bsobel]

seriously, wTF is up with everything prior to MR3-MR4.... MAD levels of anger your way for that...:|

I moved over to the team in December to fix this issues, MR4 is the first release I was involved with, I did some of performance work on it. MR5 is better (and in the pipeline)

 

[SagaLore]

Originally posted by: Goosemaster
Why is this so hard for people to understand?

It intercepts, rewrites urls, sets up a valid ssl connection between the client and the proxy,
then proceeds to proxy all requests over a legit ssl connection on the other end while maintaining a pretty url for the client the entire time.

There is a lot of mixed info about what sslstrip does. We all agree that its MiTM, but what it actually does with the end-user was the confusing part. We're arguing about really fine details, not the big picture.

Codewiz kept stressing for us to watch the end of the video... I just finished it. He's right concerning what the end-user sees. Its an HTTPS look-alike. Okay one more time...

- Performs Man-in-the-Middle on the (plaintext) HTTP connection
- Replaces all the HTTPS links with HTTPS look-alikes
- Communicates with the end-user's web browser with look-alike HTTPS for any secure link
- Communicates with the web server over HTTPS for the same secure link
- SSLstrip acts as a proxy between the end-user and the web server
- SSLstrip captures POST
- Page is forwarded back to real HTTPS page

end-user <--(bad https)--> sslstrip <--(good https)--> web server

 

[Codewiz]

Originally posted by: SagaLore

Originally posted by: Goosemaster
Why is this so hard for people to understand?

It intercepts, rewrites urls, sets up a valid ssl connection between the client and the proxy,
then proceeds to proxy all requests over a legit ssl connection on the other end while maintaining a pretty url for the client the entire time.

There is a lot of mixed info about what sslstrip does. We all agree that its MiTM, but what it actually does with the end-user was the confusing part. We're arguing about really fine details, not the big picture.

Codewiz kept stressing for us to watch the end of the video... I just finished it. He's right concerning what the end-user sees. Its an HTTPS look-alike. Okay one more time...

- Performs Man-in-the-Middle on the (plaintext) HTTP connection
- Replaces all the HTTPS links with HTTPS look-alikes
- Communicates with the end-user's web browser with look-alike HTTPS for any secure link
- Communicates with the web server over HTTPS for the same secure link
- SSLstrip acts as a proxy between the end-user and the web server
- SSLstrip captures POST
- Page is forwarded back to real HTTPS page

end-user <--(bad https)--> sslstrip <--(good https)--> web server

I only stress it because one of the things I always tried to teach my mom was look for https in the address bar and make sure it isn't giving you certificate errors. Up until now, that pretty much kept her safe. My mom does travel a lot and uses public access points. It is just a fact of life. She isn't savy enough to use VPN or ssh tunneling. The best I can do at this point is now instill that she MUST type https prior to any banking websites that she visits. Keep in mind that my mom is one of the people that types wachovia.com into google to get to the website. Call her stupid or whatever but she is in her 60's and whatever works, works.

Most tech people that keep up with this stuff won't fall for this trick now. But my mom would fall for this trick today and would well into the future without someone teaching her how to avoid it now. I believe there are a lot of people that are in the same boat.