SSLStrip Now In the Wild

An anonymous reader writes "Moxie Marlinspike, who last week presented his controversial SSL stripping attacks at Black Hat Federal, appears to have released his much-anticipated demonstration tool for performing MITM attacks against would-be SSL connections. This vulnerability has been met with everything from calls for more widespread EV certificate deployment to an even more fervent push for DNSSEC."

Re:Alternatives

[Anonymous Coward]

dude at informationweek wrote this [informationweek.com]. looks like not much end users can do.

Not the end of the world

[DigitalSorceress]

Reading TFA, it seems to me that there IS something that the end user can do to protect themselves: Look for the https:/// [https] in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK... the padlock should be down in the statusbar area where it always is.

Out of reflex, I always check that my URL starts with https:/// [https] and I check the cert when I'm dealing with someplace new. Now, I'm just always going to check the cert... even if I'm connecting to a site I use all the time.

If Moxie really wanted to make things tougher, they could maybe add a cert to their tool. THAT would make it so you'd only notice if you read the cert and realized it wasn't what it was supposed to be.

THAT's scary.

Re:Alternatives

[hal9000(jr)]

Apparently this only affects those who don't pay attention...nothing to see here.

Can you make the claim you are 100% vigilant 100% of the time?

It's more subtle than that. It takes away one of the biggest indicators that there is an SSL problem--the dialogs. Watch the presentation video [blackhat.com]. It's pretty cool. What Moxie shows is that often the indicators of SSL enabled and not enabled are practically non-existent. It's easy to see how most users, even tech savvy ones, could be fooled.

Re:Alternatives

[SuperNothing307]

Check to see if the URL to the site begins with http:/// [http] before you login. If it does, and it's displaying a padlock icon (suggesting that it is 'secure'), then you're being attacked. Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.

Also, as interesting as this attack is, it should be noted that it does require the attacker to have network access (so he can perform the MITM attack, usually through ARP spoofing). There are a number of ways to fight arp spoofing, but if you're on a small network, just set static arp tables on your machines and you've done pretty much all you can do. The attacker can still attempt to get access at your ISP and on the other end, at the web host, but handling that much traffic without being noticed would be difficult, so I doubt one would try it. (and I'm sure someone will now prove me wrong...:P)

Re:Sounds ugly

[hal9000(jr)]

SSL is NOT broken. It is still an effective way to encrypt network traffic.

The attack breaks down two ways. Proxying web traffic between a user and a sensitive site like a bank and/or repsenting a URL to a user that looks legitimate but isn't.

The indicators that you are on an SSL site are varied. A lock in the lower right of the window (FF3), to the right of an address bar (IE 6 and below), or a green address bar (IE7 EV cert) or a green indicator to the left of the address bar (FF3). All except the EV SSL certs are pretty subtle. The success relies on the fact that there are so many varied ways that SSL protection is presented to the user, can you keep track of it all. Quick, which sites use EV certs? You don't know so you don't know what to expect.

So, the attack does a couple of things to fool you. First it proxies your web traffic to secure sites re-writing urls that start with HTTPS to HTTP. The only indicator in browsers is no lock. If you are not looking for it, then you probably won't miss it. But wait, since we are rewriting URL's, why not replace the favicon with a lock. Yummy.

The second type of attack is to proxy HTTPS to HTTPS, but this time the SSL session between you and the proxy is enabled with a valid and trusted SSL certificate. No SSL dialog boxes. Here is how it works. IDN is used so that countries can represent URL in their native character sets. Some non-ascii characters look like characters. So use them to fool the user. These are called homographs. Browsers will convert some IDN based on the TLD. But other TLD, like country codes TLD, the browser won't. The assumption being a .com hostname should be ASCII while a TLD for China should be IDN. Knowing that, get a hostname in a CC TLD. Get a certificate for your hostname. Then create a really long hostname using IDN so that the TLD portion will be pushed off the end of the address bar. You can forge any legitimate web site this way and the only indicator is either examining the certificate or looking at the TLD in the URL. There are IDN that look like slashes, so making a "path" is easy.

Moxies video is pretty clear.

SSLStrip redirects to index now

[exloterum]

It's completely different. He's had SSLSniff listed on there for awhile now. All requests made to SSLStrip now redirects to the index page. Maybe he doesn't want to exceed his bandwidth?

Re:Security is a social issue. Educate!

[QuoteMstr]

They handing out mod point to everyone these days or what?

No, they must be handling out mod points to people who have a fucking clue how SSL works. SSL is designed specifically to counter your simplistic scenario.

the mitm intercepts (and blocks) client's attempt to start an ssl session with bank, instead the mitm makes the ssl connection with the bank AND the client. Where is your https and padlock icons now?

The MITM won't be able to give the client the proper certificate for the domain name the client thinks he's connecting to. The browser will detect this mismatch and give the user a broken padlock icon and a security warning. Because we've educated the user, he'll know to look for the padlock icon, and that a broken padlock icon means "danger". Attack averted.

Firefox Helpies

[cakefragment]

about:config

browser.identity.ssl_domain_display

Set it to 2 to see the Common Name of the cert in the address bar. Very helpful to see side-by-side with the URL. EV certs will still show the Organization and Country, but it makes non-EV certs a little more obvious.

Re:Alternatives

[tom17]

Lock icon? No.

Re:Alternatives

[daveewart]

The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.

In general, yes, but one of the 'tricks' of sslstrip is that it changes the content of the HTTP-served page so that the (formerly) HTTPS submission page is no longer HTTPS, but HTTP.

Re:Alternatives

[mrcaseyj]

>as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted.

No, If any part of a page is not encrypted then an attacker can effectively strip all encryption from the entire page. See this page from a Microsoft Internet Explorer programmer: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx [msdn.com]
and this page about airpwn where attendees at a security conference had the images in their web pages turned upside down.
http://www.informit.com/guides/content.aspx?g=security&seqNum=158 [informit.com]

Say for example you're using an unsecured wireless access point at an Internet cafe. There can be an attacker five miles away with a high gain antenna listening for someone to log into their bank by a login page that only encrypts the password. When your computer sends out the request for your bank's page, if the hacker's computer is fast enough, it can impersonate the wireless access point and send a version of your bank's login page with the password encryption stripped and the password redirected to whatever computer your attacker wants. When the real server finally responds to your request a few milliseconds later, your computer will think it's a mistaken duplicate and ignore it. This is not a theoretical attack, it has been publicly demonstrated. Your first login attempt may fail as the password is redirected to the attacker, but once your attacker has your password, he can return things to normal so your second login attempt will succeed. You'll just think you mistyped the password on the first try.