Forgot your password?
typodupeerror
Security The Internet

SSLStrip Now In the Wild 208

Posted by CmdrTaco
from the not-the-marisa-tomei-kind dept.
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."
This discussion has been archived. No new comments can be posted.

SSLStrip Now In the Wild

Comments Filter:
  • Alternatives (Score:4, Interesting)

    by jetsci (1470207) on Monday February 23, 2009 @10:53AM (#26957343) Homepage Journal
    I guess the question then is, what do we use as an alternative? What can we even do?
    • Re: (Score:2, Informative)

      by Anonymous Coward
      dude at informationweek wrote this [informationweek.com]. looks like not much end users can do.
    • Re:Alternatives (Score:5, Informative)

      by SuperNothing307 (1399851) on Monday February 23, 2009 @11:15AM (#26957553) Homepage
      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: (Score:3, Insightful)

        by 3p1ph4ny (835701)

        Check to see if the URL to the site begins with http:/// [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

      • by dachshund (300733)

        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.

        Try Wachovia's site: http://wachovia.com/ [wachovia.com]

        Lock icon: check.
        Unsecured HTTP page: check.

        I don't have a Wachovia account, so I can only assume that the actual UID/password info goes over SSL, but that's irrelevant to this at

      • Re: (Score:3, Interesting)

        by Dekortage (697532)

        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.

        • Re:Alternatives (Score:4, Informative)

          by daveewart (66895) on Monday February 23, 2009 @04:02PM (#26961077)

          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 (Score:5, Informative)

          by mrcaseyj (902945) on Monday February 23, 2009 @05:20PM (#26961997)

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

          • Re: (Score:3, Interesting)

            by kybred (795293)

            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!

      • noscript has a function to require SSL for certain websites you specify... Other than that, don't click on links to secure sites always bookmark them or type them in manually.
    • Public key crypto-systems.

      Not buying anything online via the web-browser.

      OK, that last is crazy talk.

    • Re:Alternatives (Score:5, Insightful)

      by Lord Ender (156273) on Monday February 23, 2009 @12:49PM (#26958625) Homepage

      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.

    • For those interested, the original paper can be found here:
      http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf [blackhat.com]
  • by DigitalSorceress (156609) on Monday February 23, 2009 @11:08AM (#26957497)

    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.

    • by IBBoard (1128019) on Monday February 23, 2009 @11:18AM (#26957591) Homepage

      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/ [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/ [paypal.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).

      • Re: (Score:3, Interesting)

        by QuoteMstr (55051)

        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/ [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/ [paypal.com]

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

        • Re: (Score:3, Interesting)

          by hal9000(jr) (316943)
          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?
        • Re: (Score:3, Insightful)

          by QuoteMstr (55051)

          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 nam

          • What if the address bar highlighted the portion of the address that is the domain name? It would then be obvious if the domain name was being spoofed.

            • by QuoteMstr (55051)

              That's another good idea, but I think users might not be alarmed by seeing the entire address bar highlighted in that way as long as it still reads paypal.com/foo/bar/qux/blah/blah/blah. Again, it's the difference between making a security indicator subtle and making it almost impossible to miss.

            • by chihowa (366380)
              I've been playing around with the Windows 7 beta and whatever IE version it uses does that. "domain.tld" is black and the rest of the address is grayed out. I was actually pretty impressed, though I'm not sure how it works with very long addresses.
            • The answer is not so much to highlight the domain name (it can be very long in some spoofing URLs). It is to show clearly the [most significant parts of the] top level domain - if necesary in a separate area. HOW it's done is a matter for the browser developers, but the INFORMATION needs to be made clear to users. Highlighting the domain name MAY be one way to do that, but teh answer depends on screen real estate available, user expertise, and other factors.

              The end result is no more confusing MyBank.blah.

    • by Vellmont (569020)


      Look for the https:/// [https] in the address bar and DON'T LOOK THERE (favicon.ico area) FOR THE PADLOCK

      So great.. you teach everyone to LOOK FOR THE HTTPS, and that means you're safe!

      Then, the attackers simply use a variant of the (similar URL method), and are sure to include SSL, so the URL is (for example) https://www.mybank.com.com.cn/ [com.com.cn] (or whatever fools the user).

      Even if you could somehow re-train millions of people successfully to understand one particular attack mode, another one will always be right aroun

      • The real problem is the browser makers do not care about security. They only care about the appearance of security.

        For example, browsers don't do the SSH style thing where they warn you if the cert changes for a previously recognized site.

        Go look at all the built-in CA certs in your browser sometime. Count them if you can.

        How sure are you that none of the CAs there won't be tricked/bribed into signing a cert for *.mybank.com ? Who has audited them?

        All it takes is just one CA, and AFAIK, none of the popular
        • by QuoteMstr (55051)

          It's all just a show to make the sheep feel safe.

          The problems you identify with the CA infrastructure are real, but switching to an SSL-style OH-MY-GOD-THE-CERT-CHANGED system introduced vulnerabilities to several different attacks, desensitizes users to security problems, and cannot provide assurance of identity --- only that the site is the same one that you spoke to last time.

          Closing your eyes, plugging your ears, and singing "la la la ssh la la la self-signed la la la" won't solve a single thing when so

        • by Vellmont (569020)


          The real problem is the browser makers do not care about security. They only care about the appearance of security.

          I largely agree. If I had a "secure" browser to use, I'd use it to do all my banking with. Online purchases I don't so much care about as the CC company is really the one taking all the risks.

          • You can use a separate browser to do your banking with more secure settings, so even if it is not really more secure software-wise, it can be more secure in configuration. I do that actually.

            If you're using windows use "run as".

            e.g.
            Say you have an account called vellmont.
            Create an account called _www_vellmont and make its home directory fully accessible by your vellmont account.
            Then in your vellmont account, create a shortcut:

            C:\WINDOWS\system32\runas.exe /profile /user:COMPUTERNAME\_www_vellmont "C:\Progra
            • by QuoteMstr (55051)

              Start->Run firefox -ProfileManager -no-remote

              Create a profile called, say, 'bank'.

              Then run
              Start->Run firefox -Pbank -no-remote

        • The problem with your proposal is that sites must change certificates once every few years. So now, every three years the certs change and your browser complains. Say you visit 36 ssl sites. That means that you will have a ssl-alert about once a month - you will just click through, and not check.

          In addition to that, this attack, for example, would bypass that! You visit www.mybank.com - all is good, no ssl. You are then redirected to secure.theevilbank.com - again, all is good because secure.theevilban

  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday February 23, 2009 @11:08AM (#26957501)

    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.

    • by IBBoard (1128019)

      We need to train users to look for the browser padlock icon

      But this can spoof that as well for many users (and even for Firefox users it might make the unwary feel safe).

      We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user.

      He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than https://yourbank.com.some.evil.website. [website.com]

      • by QuoteMstr (55051)

        He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than

        This problem is easy to solve technically with an IDN character blacklist. The https-to-http redirection is far more insidious.

        HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the s

        • What I don't understand is that Firefox _used_ to change the address bar text area background color to pale yellow to indicate a secure site and it stopped doing that some time ago. I always thought that was a great feature and much more obvious than that tiny little icon on the status bar, which can be lost in the noise next to the Greasemonkey icon and the NoScript icon, etc.

      • by Culture20 (968837)

        HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the status bar section?

        Why can't a favicon start with a blue background? Can't a favicon from the target site get a new blue background dynamically easily? Who pays attention to the status bar? What about TFA's assertion of being able to use

        https://login.paypal.com|login.php?oEEnt39ju4wHEhehw&=$*Y$JJSFJIsEE36879899696969696933...200morecharacters.fakedomain.ru

        with a real SSL cert for fakedomain.ru? Note, apparently | can be a character that is not | or / but shows up just like /

    • Education won't actually help. Most users do not know what a certificate is for. They have been trained to know that if a secure icon is present it's good. Many will have a basic knowledge that a secure connection is a sign that the info they send can't be eavesdropped; and maybe that it has something to do with being stored safely on the bank's (or whatever) web site.

      When web browsers or people start talking about certificates, eyes glaze over. Most people don't know what a certificate is. If they g

      • by QuoteMstr (55051)

        Most users do not know what a certificate is for....They have been trained to know that if a secure icon is present it's good.

        You're right. We can't count on users being any more than idiots. They'll just look for a secure icon. The trick is convincing them to look for the correct security icon, and to check that the address in the browser matches the site in the window.

        These techniques are very simple, on par with looking both ways before crossing the street. I think almost everyone can be taught basic due

    • by Jay L (74152) *

      We need to train users to be vigilant, because nasty people are trying to steal their information.

      Why is that any more likely to work than training people not to be nasty?

    • by jddj (1085169)

      The solution is user education.

      fail.

      You're dealing with average people, not bright geeks. People won't read. They don't learn, and arguably they shouldn't need to do so to use someone's web site.

      People - even some knowledgeable IT folks I know - think that the "lock" icon means an entire transaction, from client to server, is secure - not just that a transaction is conducted through an encrypted pipe.

      They think the lock means:

      • "you have to have a password to use this site"
      • "the web site is specially protec
  • EV certificates (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.

    • by QuoteMstr (55051)

      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.

      That's still impossible unless you're okay with the client getting the wrong certificate. In a corporate environment, you can just install a CA certificate in every client and the user will be none-the-wiser. But in general, SSL is not vulnerable to undetected MITM attacks.

    • by blueg3 (192743)

      If you've paid for digital certificates, shouldn't you know what level of validation they've been doing?

      Also, as far as I know, all modern browsers support EV certificates, but not all of them differentiate EV certs from regular ones. Firefox 3, however, does.

    • by The Moof (859402)

      Makes you wonder, what level of validation they've been doing for the past few years.

      If the credit card making the purchase was declined or not.

      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.

      • Re: (Score:3, Insightful)

        by QuoteMstr (55051)

        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 ar

        • Re: (Score:3, 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

          • Re: (Score:3, Insightful)

            by QuoteMstr (55051)

            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 l

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

              If FooCA just gives BarInc a cert, how do they extract any sort of payment from the visitors? Once the cert is in the wild, anyone can use it to verify BarInc.com. So FooCA would have to not provide it to anyone until asked (and paid) by one of their customers.

              The CA is only involved in issuing the certificate, nobody talks to them per site visit. Having the visitors instead of site owner pay the CA would require changing this, which doesn't seem feasible.

              I'd rather have a robust CA system so that nobody has to be in that group of fooled people

              It shouldn't be the users getting fooled, just some

    • You are wrong. It is impossible to MITM properly-implemented SSL without having access to a trusted CA.

    • by LanMan04 (790429)

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

      IE7 does
      Firefox 3 does
      Safari does

      So what browsers don't that people actually use? No, Opera doesn't count. :)

  • Hype (Score:2, Interesting)

    by TheRealJobe (1125771)
    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.
  • 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?
  • I'm going to stick my neck out and say that SSL is a false security. Any twit with $29.95 can buy an SSL cert. The mere fact that a page is encrypted via SSL seems to convince people that they are dealing with a reputable site.

    I'm much less worried about packet sniffing, and more about fake sites like I see every day in the steady flow of spam. There are many ways to steal someone's private data, all much easier than being on the right network, at the right time, sifting through gbits/sec of garbage for

    • by QuoteMstr (55051)

      I'm going to stick my neck out and say that SSL is a false security....I'm much less worried about packet sniffing, and more about fake sites

      SSL works very well for the kind of attacks it was designed to counter. We need other mechanisms to protect against others. Why would you expect one technique to cover all vulnerabilities?

      Major browsers already include anti-phishing features that check blacklists. These blacklists will reduce, but not completely eliminate, the fraud caused by phishing schemes. A few pe

    • Geez, $29.99? Where do you buy your certs? You are getting ripped off. Last one I bought was $9.99.
  • Firefox Helpies (Score:2, Informative)

    by cakefragment (1484945)

    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.

I'm all for computer dating, but I wouldn't want one to marry my sister.

Working...