Hawaiʻi's Technology Community
Browser SSL attacks presented at Black Hat...
Moxie Marlinspike gave a presentation titled: "New Tricks for Defeating SSL in Practice" at the Black Hat conference last week and released code that demonstrates practical, man in the middle based, attacks on browser security.
The results are a bit depressing, but not entirely new or unexpected. The attacks that he presented in the talk mostly skirt around SSL and while they appear to be effective they aren't really attacking SSL so much as the way we use SSL and how browsers present information.
The overall theme is that browsers have shifted away from gaudy, positive re-enforcement on secure sites towards negative feedback when something "bad" is detected. So as long as hackers don't trigger the "bad" flags users now tend not to notice. The talk also point out a deeper problem that is not easily addressed with simple browser changes - that is that most traffic starts out as http and then migrates to https, leaving a huge hole for man in the middle (MITM) attacks.
The talk boils down to the following:
0) There used to be an egregious bug in certificate verification that blew up everything (you could create certs for whatever you want). That's been fixed in most cases and so he moves on to other topics. Although he does imply that he has more tricks in this area that he isn't sharing with us.
1) For everything that follows you need to get into a position to do a MITM attack. He claims that this is really easy via ARP spoofing, etc. where you trick a client into thinking that you are the network gateway. To me this seems like a bigger problem than anything that follows, but I believe them when they say that it's hard to fix.
2) You exploit the fact that most secure sites either redirect from insecure (http) servers or blatantly start from an insecure page and post login over https from there. Since you are a MITM you just rewrite the pages to strip out the https.
Most of his talk is about #2, which I agree is serious, but basically obvious stuff stemming from being a MITM.
3) He discusses ways to make #2 appear more secure to the user by:
a) Putting up a fake lock icon on the page favicon.
b) Using international domain name lookalikes to put up your own https secured fake sites that front your MITM to the real back end. With this you get the real secure site indicators in the browser.
c) Using a nasty IDN lookalike for https:// that lets you shove the true domain name off the address bar. This gives you point b above but with no visible indication at all.
Point a is "meh", not too exciting.
Point b seems to have been taken care of to some extent in Firefox by not displaying international character sets for some domains like .com.
Point c looks *really* nasty but seems to have obvious fixes in the browser. i.e. stop displaying things that look like http(s):// as part of a subdomain. Maybe I'm naive, but the URL spoofing attacks seem like something we can fix in the browser given a little more thought.
People asked many questions at the end: About half just missed the point that you're a MITM and can rewrite anything the site puts in the page. The other half wanted new kinds of authentication mechanisms supported either by DNS or the sites. The speaker points out that as long as not all sites implement the new features client browsers can't rely on them and can't even "test" for them properly because of DOS attacks.
The speaker notes at the end that it appears that the only solution is https-only sites with a browser side registry of secure sites. Any traffic starting out as http:// is subject to MITM.
The results are a bit depressing, but not entirely new or unexpected. The attacks that he presented in the talk mostly skirt around SSL and while they appear to be effective they aren't really attacking SSL so much as the way we use SSL and how browsers present information.
The overall theme is that browsers have shifted away from gaudy, positive re-enforcement on secure sites towards negative feedback when something "bad" is detected. So as long as hackers don't trigger the "bad" flags users now tend not to notice. The talk also point out a deeper problem that is not easily addressed with simple browser changes - that is that most traffic starts out as http and then migrates to https, leaving a huge hole for man in the middle (MITM) attacks.
The talk boils down to the following:
0) There used to be an egregious bug in certificate verification that blew up everything (you could create certs for whatever you want). That's been fixed in most cases and so he moves on to other topics. Although he does imply that he has more tricks in this area that he isn't sharing with us.
1) For everything that follows you need to get into a position to do a MITM attack. He claims that this is really easy via ARP spoofing, etc. where you trick a client into thinking that you are the network gateway. To me this seems like a bigger problem than anything that follows, but I believe them when they say that it's hard to fix.
2) You exploit the fact that most secure sites either redirect from insecure (http) servers or blatantly start from an insecure page and post login over https from there. Since you are a MITM you just rewrite the pages to strip out the https.
Most of his talk is about #2, which I agree is serious, but basically obvious stuff stemming from being a MITM.
3) He discusses ways to make #2 appear more secure to the user by:
a) Putting up a fake lock icon on the page favicon.
b) Using international domain name lookalikes to put up your own https secured fake sites that front your MITM to the real back end. With this you get the real secure site indicators in the browser.
c) Using a nasty IDN lookalike for https:// that lets you shove the true domain name off the address bar. This gives you point b above but with no visible indication at all.
Point a is "meh", not too exciting.
Point b seems to have been taken care of to some extent in Firefox by not displaying international character sets for some domains like .com.
Point c looks *really* nasty but seems to have obvious fixes in the browser. i.e. stop displaying things that look like http(s):// as part of a subdomain. Maybe I'm naive, but the URL spoofing attacks seem like something we can fix in the browser given a little more thought.
People asked many questions at the end: About half just missed the point that you're a MITM and can rewrite anything the site puts in the page. The other half wanted new kinds of authentication mechanisms supported either by DNS or the sites. The speaker points out that as long as not all sites implement the new features client browsers can't rely on them and can't even "test" for them properly because of DOS attacks.
The speaker notes at the end that it appears that the only solution is https-only sites with a browser side registry of secure sites. Any traffic starting out as http:// is subject to MITM.
Views: 151
Comment
-
Comment by Pat Niemeyer on March 1, 2009 at 5:46pm
-
yah, the problem is that we have a legacy world where all of the browsers will try http first, leaving them open to the attack. And even if we mandate that browsers try https first, as long as http still exists as a fallback for sites that don't require https, then an attacker can do a DOS (denial of service) attack on the https service and trick people into thinking that it doesn't exist, causing them to fall back to http.
-
Comment by Cameron Souza on March 1, 2009 at 5:36pm
-
As networks get faster, why not just make https the default for everything?
-
-
Kinda interesting, but really none of this is new.
I agree that there is not much technically new here. However putting all of these pieces together really does paint a dire picture of where things stand right now.
On your first point about DNS and names - I think that certificate validated names can be meaningful as people who have grown up seeing yahoo.com and variations in their address bar and who get used to some visual cues will learn to expect these things. And that is why I think the fake subdomain issue that he points out is really alarming. But again, I expect that we can fix those types of problems in the browser.
The really nasty thing that he points out that should have been (but probably wasn't) obvious to everyone is that the convention that people have learned and browsers have codified to start with http and migrate to https totally undercuts secure web traffic.
Even if we somehow magically insure that the browser hasn't been compromised and get rid of the naming games, in the current environment where people bounce between http and https a hacker can always get in the middle. The only solution is for people to manually type https:// or for the browser to maintain a list of these sites (problematic in its own right).
-
-
Well, he sort of skips over this and just briefly mentions ARP spoofing or ARP cache poisoning. So, that presupposes that you have access to the physical or wireless network and then you try to trick the clients into thinking that you are the gateway. ARP is the address resolution protocol. It's broadcast based so you can either use the race condition and try to respond before the real gateway responds or you can exploit a caching mechanism by constantly broadcasting yourself as the gateway.
Once the client believes you are the gateway you have every packet that they send.
-
Comment by Truman Leung on February 24, 2009 at 6:04am
-
Pat, this is interesting! How does a hacker get to the MITM stage on a unencrypted page?
© 2024 Created by Daniel Leuck.
Powered by
You need to be a member of TechHui to add comments!
Join TechHui