Phishing as a man-in-the-middle kind of attack

I gave a presentation to the Liberty Staff yesterday about Phishing as an MITM attack, and what can be done about it. I think it went very well, and I’m very excited that I’ll be meeting people I didn’t know who are working in this space, and that we could have a significant impact on the future of web authentication and in ridding us of phishers.

I don’t have enough time to give this topic a complete treatment in this blog entry, so I’ll stick to a very short summary. The Internet-Drafts and links to them that are relevant here are linked to in earlier blog entries of mine. Rest assured though, I will be writing more link-rich blog entries about this topic soon enough, and I’ll post my presentation once I add a few more slides (mostly to include relevant links and to give credit where it’s due — I had to limit myself to two slides for the presentation itself!).

The gist of this presentation was: phishing is not about stealing passwords, it is about stealing our money — passwords are gravy to a phisher. If we replace cleartext passwords in HTML forms POSTed over https as our predominant method of web authentication, but aren’t careful enough to defeat MITM attacks then phishers will still be in business, and they’ll still steal our money. Note that there are practical MITM attacks that phishers can and do mount that are not on-path attacks (i.e., the phisher need not be in the route path from the client to the server) — think of URLS like “http://www.yourbank.tld:sdfjkfgsdf@clever-phisher.tld/login.php”.

It’s crucial that we understand that neither DNS registrars nor certificate authorities care to help, nor are they in a position to help us defeat phishing.

Here’s where Project Liberty comes in: federations, by dint of being much smaller than the Internet as a whole, can help. Federations can help by providing a way to authenticate relying parties to user agents, or at least by providing a relying party authorization function for user agents — given this then federations can act as whitelists and keep the phishers out. There is a crucial UI element here though: users need to be able to know what identity they used to authenticate to some server, what the server’s name is and what the name of the federation is that mediated mutual authentication.

Besides the message that federated mutual authentication provides a mechanism to keep phishers out, there’s also the issue of ensuring that there are no practical MITM attacks left to phishers. This is where channel binding comes in. If authentication happens about the HTTP/TLS layer, then we need to make sure that the server we think we’re talking to at that layer is the same as the one at the HTTP/TLS layer, or we have to make sure that all messages to the server are additionally proteted about the HTTP/TLS layer (this last is never going to happen). So either we push authentication down the stack, to the HTTP/TLS layer, or we need to provide some way to bind web authentication to the HTTP/TLS “channel.”

I described several ways to do the channel binding and mutual authentication.

Credit for these ideas, by the way, goes to Sam Hartman, Leif Johansson, and the IETF usual suspects who helped refine them (Jeff Hutzelman, Jeff Altman, Love Hörnquist, RL “Bob” Morgan, and Lisa Dusseault, Chris Newman, and many others).

~ by nico on October 11, 2007.

One Response to “Phishing as a man-in-the-middle kind of attack”

  1. Hello –
    I hail from the second largest Certification Authorities on the planet – Comodo. And in part I agree that much needs to be done to strengthen internet mutual authentication. I do take exception to the idea that CA don’t care. In fact, we GIVE away free authentication technology to consumers that verifies web content and thus the identity of a site.

    The problem with much of the verification technologies out there is that the displays are browser based indicator – hence spoofable. We have technology that prevents MITM attacks called Content Verification Certificate (CVC). Here’s a quick lowdown on how it works. Sites decide which content they want to protect. Typically, banks will protect their log in box. The site installs a CVC and the user gets free plugin called VerificationEngine which checks the site for CVC’s. When a user mouses over secured content, such as log in box on a bank site – the real site would display a NON BROWSER BASED green border. That’s the key. Since the authentication confirmation is not coming from the browser but from the computer – it is not spoofable. (Boiling Springs Savings banks uses this technology today for instance). In fact, we have over 200,000 home page logos in our database that are authenticated which consumers can authenticate.

    So some CA’s do care – we give away VE for free and our certificates cost just a few hundred bucks. That’s how we are doing our share 

Leave a Reply

Your email address will not be published. Required fields are marked *