Slashdot Mirror


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

35 of 208 comments (clear)

  1. Alternatives by jetsci · · Score: 4, Interesting

    I guess the question then is, what do we use as an alternative? What can we even do?

    --
    Bored at work? Play Game!
    1. Re:Alternatives by Anonymous Coward · · Score: 2, Informative

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

    2. Re:Alternatives by jetsci · · Score: 5, Funny

      It's called a shotgun.

      --
      Bored at work? Play Game!
    3. Re:Alternatives by jetsci · · Score: 2, Funny

      But did he get the combination number to her chastity belt? I haven't actually seen the thing but it must exist since I can't get anywhere near there...

      --
      Bored at work? Play Game!
    4. Re:Alternatives by hal9000(jr) · · Score: 4, Informative

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

    5. Re:Alternatives by SuperNothing307 · · Score: 5, Informative

      Check to see if the URL to the site begins with 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)

    6. Re:Alternatives by Lostlander · · Score: 2, Funny

      Watch out for Packet Loss It can be quite high in certain areas especially if you're rural. Also be aware of Hackers

    7. Re:Alternatives by 3p1ph4ny · · Score: 2, Insightful

      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.

      Even this doesn't work. Legitimate banks do this (http://www.usbank.com is one, who I've banked with in some fashion since I had a net worth of over $50). Note that after you type your username in, you're taken to a secure page.

    8. Re:Alternatives by Lord+Ender · · Score: 5, Insightful

      We don't need an alternative to SSL. We need browsers to implement proper UI. The user MUST be made aware if clicking a button would transmit a password in cleartext. The user MUST be made aware exactly which domain they are connected to during an SSL session. On a large busy screen, a tiny bit of text in a corner is the wrong way to do this.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    9. Re:Alternatives by Dekortage · · Score: 2, Interesting

      Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.

      Maybe. 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. Conversely, if you have an HTTPS login form, but the form action goes to an HTTP site, your credentials are NOT encrypted.

      --
      $nice = $webHosting + $domainNames + $sslCerts
    10. Re:Alternatives by tom17 · · Score: 2, Informative

      Lock icon? No.

    11. Re:Alternatives by daveewart · · Score: 3, Informative

      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.

      --
      "If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
    12. Re:Alternatives by mrcaseyj · · Score: 4, Informative

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

      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.

    13. Re:Alternatives by kybred · · Score: 2, Interesting

      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.

      That's why I always type my password in wrong on purpose the first time!

  2. Re:Sounds ugly by ^BR · · Score: 5, Insightful

    You could also try to read about it... The problem is not with SSL, it's with an attacker redirecting the traffic before it is in SSL, as your typical banking session usually start in plain HTTP. People then fail to understand the visual clues given by their browser. This attack is a nice technical MITM/social engineering mix, countermeasures are not really purely technical, if banks stopped to be cheap and did all their serving over HTTPS there would not be any HTTP traffic to modify in the first place...

  3. Not the end of the world by DigitalSorceress · · Score: 5, Informative

    Reading TFA, it seems to me that there IS something that the end user can do to protect themselves: Look for the 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:/// 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.

    --

    The Digital Sorceress
    1. Re:Not the end of the world by IBBoard · · Score: 3, Interesting

      If you read some of the articles (Forbes and a linked one) he can spoof the appearance of a valid certificate as well using International Domain Names. The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/

      For the basic attack then actually checking for HTTPS and a proper validation (not just a padlock, but a padlock and the other markers), but for the fuller attack that takes advantage of the IDN then you'd probably need to read the certificate itself, which would require you to know which certificate you're expecting, which would require something like a page with the signature on saying "look for this", which could then also be spoofed (in cases where it was worth it, e.g. a bank).

    2. Re:Not the end of the world by QuoteMstr · · Score: 2, Interesting

      The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/

      Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unnecessary.

      The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.

    3. Re:Not the end of the world by hal9000(jr) · · Score: 2, Interesting

      The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.

      Do you know if FF will detect blacklist characters for all TLD's or just the non-IDN TLD's like .com and .net?

    4. Re:Not the end of the world by QuoteMstr · · Score: 2, Insightful

      Another, perhaps more reliable option would be to change how long URLs are displayed.
      Right now, if a domain name exceeds the length of the address bar, it's truncated on the right. Consider:
      www.paypal.com/foo/bar/qux/sessionid/12341/do.myevildomain.com. If this URL is displayed as:

      www.paypal.com/foo/bar/qux/sessionid/123

      the user will be fooled. What if, instead, the truncated domain name looked like this?

      www.paypal.com/foo/bar/...341/do.myevildomain.com

      That way, no matter what evil junk is in the domain name, the user will see both its beginning and end and know something strange is going on.

  4. Security is a social issue. Educate! by QuoteMstr · · Score: 5, Insightful

    This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.

    The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.

    I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!

    The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.

    1. Re:Security is a social issue. Educate! by QuoteMstr · · Score: 5, Informative

      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.

  5. Huge pet peeve by QuoteMstr · · Score: 4, Insightful

    A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.

    I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.

    1. Re:Huge pet peeve by QuoteMstr · · Score: 4, Insightful

      IE's warning appeared on all form submissions. I agree that warning was worse than useless.

      I'm talking about warning only when the following conditions apply:

      1. The form being submitted is on a non-encrypted page
      2. The form's action refers to a page served over HTTPS

      The user should not be able to disable the warning; its existence will lead webmasters to change condition 1.

    2. Re:Huge pet peeve by thePowerOfGrayskull · · Score: 2

      This would be great, except that most users don't read warnings. They click through them in whatever looks like the most likely path to allow them to finish what they started.

    3. Re:Huge pet peeve by QuoteMstr · · Score: 2, Interesting

      Of course users won't actually read the warning. The point is to annoy users so that webmasters eliminate the behavior causing the annoying warning.

  6. EV certificates by Lieutenant_Dan · · Score: 2, Interesting

    "for more widespread EV certificate deployment"

    That's probably being sold by Thawte. And considering that a lot of browsers out there still don't support EV.

    Extended validation? When I pay for a digital cert, I expect a high level of validation anyways. Makes you wonder, what level of validation they've been doing for the past few years.

    SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.

    --
    Wearing pants should always be optional.
    1. Re:EV certificates by QuoteMstr · · Score: 2, Insightful

      I do not like the whole "EV certification" thing. Not because I dislike the process or what it's designed to do, but because CA's were already supposed to be doing the verification in the first place (apparently, they weren't). Now they want to charge more money to do what they were originally supposed to do.

      Like most human behavior, this problem can be explained by economics.

      The problem is that the CA system creates the wrong incentives. You, as a CA, want to sell as many certificates as possible. There are almost no repercussions for issuing a fraudulent CA. In theory, browsers are supposed to remove rogue CAs from their CA lists, but in practice that doesn't happen: they're too afraid of "breaking the web" and being sued to actually punish CAs for having lax security.

      Comodo, for example, delegates its CA business to fly-by-night subsidiaries who issue certificates with no verification whatsoever. This is the worst situation imaginable from a security perspective, but even after this contemptible practice was exposed, neither Microsoft nor Mozilla Corp. removed the Comodo root certificate. I've personally removed it in all the browsers I use, but most users won't do that.

      Comodo's behavior is no surprise, however. For them, it makes sense from an economic point of view. Yelling and screaming will change nothing. The EV program is slightly better in that it's an industry agreement to perform better validation, but it'll inevitably succumb to the same market forces. As EV certificates become more entrenched, it'll become too difficult to punish rogue EV vendors, and we'll be in exactly the same situation we are today with standard SSL certificates.

      CAs validating websites and taking payment from them creates the same perverse incentives that led credit rating agencies to contribute to the current economic crisis. You can't count on people's goodwill to make them do the right thing: if you want the right thing to happen, you need to make the right thing the easy or profitable thing.

      There are a couple solutions to the incentive problem:

      1. Make users pay CAs to validate websites: this puts the economic incentives in the right place, but users will resent paying for what used to be "free". Personally, though, I'd subscribe to an enhanced validation service.
      2. Change CAs into non-profits: the problem with this approach is that funding would then have to come from the government or some other organization. Can you imagine "PayPal, stop accepting payments for contraceptives or we'll revoke your certificate, you liberal hippies"?

      I wish I could come up with better ideas.

    2. Re:EV certificates by Timothy+Brownawell · · Score: 2, Insightful

      There are a couple solutions to the incentive problem:

      1. Make users pay CAs to validate websites: this puts the economic incentives in the right place, but users will resent paying for what used to be "free". Personally, though, I'd subscribe to an enhanced validation service.
      2. Change CAs into non-profits: the problem with this approach is that funding would then have to come from the government or some other organization. Can you imagine "PayPal, stop accepting payments for contraceptives or we'll revoke your certificate, you liberal hippies"?

      I wish I could come up with better ideas.

      Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live. And unless it's ICANN running the CA, a site might need to get certs from multiple CAs if people in different countries or with different browsers want to talk to them.

      Hmm, there's a thought. Self-signed certs, with the root cert fingerprint available as a DNS record, using DNSSEC. Then get the real-world identity info from 'whois'.

      Or use something based on "can't fool all of the people all of the time" like Perspectives (see sig), where instead of having a CA that gives the site owner a certificate, there are a bunch of public servers that you ask whether they see the same key you see for whatever site you're going to.

    3. Re:EV certificates by QuoteMstr · · Score: 2, Insightful

      Having a CA funded by anyone but the website also doesn't work, since the site needs to get a certificate from the CA before going live.

      I don't see why a site requesting a CA needs to be live. Consider FooCA, a for-pay CA that users subscribe to, or that ISPs subscribe to on behalf of their users. (There are other models --- this is just an example). If BarInc wants a certificate from FooCA, BarInc just applies to FooCA as soon as BarInc incorporates and obtains BarInc.com. Why would BarInc.com need to be live at this point?

      Hmm, there's a thought. Self-signed certs, with the root cert fingerprint available as a DNS record, using DNSSEC. Then get the real-world identity info from 'whois'.

      That's a thought. But first we need DNSSEC, which would make me a happy man in any case. :-)

      Or use something based on "can't fool all of the people all of the time" like Perspectives

      That solves some problems, but I'd rather have a robust CA system so that nobody has to be in that group of fooled people. Perspectives also adds significant latency to the connection and has other technical problems, but combined with other security measures, I don't see it as being all bad.

  7. Hype by TheRealJobe · · Score: 2, Interesting

    Please don't get me wrong, this will make a nice addition to a toolbox. However, the hype I have seen tied to this tool is overwhelming. It seems like conferences have become more reliant on over-hyping items like these to promote the conference name more than anything else.

  8. Re:Sounds ugly by hal9000(jr) · · Score: 4, Informative

    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.

  9. SSLStrip redirects to index now by exloterum · · Score: 2, Informative

    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?

  10. An anarchist resource since 2004? by edgewedge · · Score: 2, Interesting

    Holy crap, looking at the source to sslstrip, this was written in 2004! I wonder if the anarchist underground hacking scene has had access to this for all that time? Why release it now I wonder?

  11. Firefox Helpies by cakefragment · · Score: 2, Informative

    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.