Cenzic 232 Patent
Paid Advertising
web application security lab

Places to MITM

40 posts remaining…

Just a quick thought for a Friday afternoon. For a while I did informal questionnaires to friends and family and people in general who aren’t hardcore security people about what they type in when they’re going to their bank. The following are the kinds of answers I’d get:

  • “I type in www.bank.com.”
  • “I type ‘bank’ and hit ctrl-enter”
  • “I type in http://www.bank.com”
  • “I type in bank.com and hit enter”

But almost never (twice out of dozens of people) I’d hear someone say, “I type in https://www.bank.com” with the “s”. So let’s just for a second think about all the problems with these. Let’s take “bank.com” as an example.

  • User types bank.com, which, depending on the browser is being sent on the wire as they type over HTTP for auto-complete
  • The browser corrects the URL to be http://bank.com/ and makes a DNS request for “bank.com”
  • The DNS server responds with an IP address
  • The user makes a request to bank.com’s IP address over HTTP
  • bank.com responds in unencrypted HTTP to the user’s browser and informs them that they should be speaking with www.bank.com, and redirects them there via a 301 or 302 redirect
  • User’s browser makes another DNS request for www.bank.com
  • DNS server responds with www.bank.com’s IP address
  • Browser makes an HTTP connection to www.bank.com
  • www.bank.com realizes that the user is connecting via HTTP and uses another redirect to send the user to https://www.bank.com (or often has a link on the page, asking the user to click it to log in which will take the user to HTTPS)
  • User’s browser re-connects to port 443 and begins negotiating - and at this point is encrypted (hopefully using strong crypto and there are no other issues…)

There’s a lot of places there than an attacker can get in the middle and mess things up. And sadly, this isn’t even close to everything wrong in real life. So while HTTPS is a good idea, in practice how people tend to get there is pretty flawed. The promise of STS, HTTPS everywhere and some of the settings within NoScript and so on… was to take that out of the user’s hands. Not that these aren’t all good ideas, but there are usability issues, and require that the user be somewhat informed of the issues in most cases - which they don’t tend to be.

22 Responses to “Places to MITM”

  1. Sri Says:

    Reminds me of SSL Strip - http://www.thoughtcrime.org/software/sslstrip/. It pretty much puts your notes in action.

  2. RSnake Says:

    @Sri - you’re precisely correct… we’ll be talking about Moxie’s tool a little at Blackhat in July as well - not much, but it’s good background information for the preso.

  3. Peter Says:

    Your seconds last point is wrong.

    Most banks, at least in Sweden, doesn’t even do that, not until you click the login button on the http site you will be directed to the https version.

    Some sites event doesn’t allow https for visitors and redirects the other way around.

  4. ikoz Says:

    most people i know dont even know the site of their bank.
    they just put the name of the bank (or part of it) in the search box (or ..omnibox) and click the first result that has the name of the bank as a title…

  5. Ramki B Ramakrishnan Says:

    “I Google ‘bank’ and click the link” is missing

  6. Sasha Says:

    Long time I proposed the idea for banks to give their customers a simple bookmarklet with the SSL link in it. Then they only need to click the bookmarket. This stops phishing too, if banks make clear that they can only enter their online banking server through SSL. The only thing banks then need to do is explain the user to drag the bookmarklet, or if they are total retards make an installer for it.

    Simple and effective ;)

    That said, I still wonder banks do not supply their own desktop browser that exclusively can browse their IP. Lot’s of software has embedded explorer shells running, Skype does, so does Macromedia/Adobe.

  7. lala Says:

    You forgot the first steps
    1. I type in google in the box
    2. I type “my bank” in the google search box
    3. I click on one of the top three results…

  8. Wornstrom Says:

    Maybe this is something to consider at DNS level. When the server gives you the address of bank.com or www.bank.com it should also suggest you use HTTPS (or at least notify that it’s available), and the browser can do so without ever sending an unencrypted request to the server. Not perfect, but seems like an improvement.

  9. Wornstrom Says:

    …or heck, can we just make the browsers try HTTPS first before falling back to HTTP?

  10. Chris Clark Says:

    HTTPS is designed to mitigate against DNS and other network attacks. So the bank can redirect me anywhere they please, as long as at the end of the day the browser bar says “httpS://www.bank.com”.

  11. Tom T. Says:

    Bookmark your bank’s secure login page (and watch the address bar to make sure your bookmark hasn’t been corrupted).

    (@ RSnake, but ATTN: Wornstrom)

    Some time after Steve Gibson called out Bank of America for presenting users with a NON-secure login page, and worse, with a phony black “padlock” next to the user/pass boxes (it fed the creds to a secure site, but what an opportunity to phish or MITM the insecure site!) ,,, AND Giorgio Maone added the “Force HTTPS” feature to NoScript, most banks started automatically redirecting www dot bank.com to https www dot bank.com.

    I agree that most AHU (Average Home Users) aren’t aware or won’t take any extra time. But as more banks make even their “public” portal secure, or combine it with the login page, then just bookmarking that, which should be the intuitive behavior of most users, should cut down on a lot of this. Just gotta watch those bookmarks …

  12. Tom T. Says:

    Oops, in my comment awaiting moderation, I gave the link to the generic NoScript page. I meant to give the link to the specific “Force HTTPS” feature and FAQ, which also includes the ability to catch secure sites that forget to mark their cookies as secure, and to secure them (”encrypted connections only”). That FAQ is at http://noscript.net/faq#qa6_3. Sorry.

    The FAQs right above that one have some interesting info and links on MITM, DNS hijacking, and cookie hijacking.

    @ Wornstrom: Yes. See the links.

  13. AppSec Says:

    @Sasha;
    the idea of banks building their own browser (and each bank doing it on their own) is pretty worrisome. Skype and Macromedia are their own technology basis.

    I like the idea of the bookmarklet, though.

  14. micmast Says:

    It gets even funnier if you have a XSS in your https version of the site. We did a demo once that did this exact same thing. A dns attack was used to spoof the ip of the site, we controlled the HTTP with a apache and had a ip forward on port 443. We rerouted the user to the https equivalent of the webpage with our XSS (which injected beef in the webpage, and since we controlled the HTTP portion of the page, the beef did not have restriction with same origin).

    It is a viable attack that is so often overlooked it isn’t even funny. Educate your users to use the HTTPS from the start, it will prevent heaps of troubles.

    Just my 2 cents :)

  15. tric Says:

    why the 40 posts remaining?

  16. Aurimas Says:

    then the bookmark will be the weak point and target for malware.

    Maybe browser vendors should create something like “secure tab” (similar to private browsing), which would allow only https browsing. For avarage user maybe word “secure” would mean something.

  17. Johnny Cocaine Says:

    Maybe browsers should know that when they get redirected from http to https, they should double check that the https connection is really encrypted. The “flaw” in sslstrip is that the browser knows it’s not encrypted and an alert user will notice the lock icon is not “locked”. Why not make the browser do that instead of the user?

  18. MrAnderson Says:

    The real problem stands in the browsers. Why using two different handlers one for http and the other for https? Browsers should implement recognising SSL on any handler wether http, ftp or anything else. This would permit banks to run SSL on port 80 and every customer would be secured out (but then who knows…). In this way also any other website wanting to take you over ssl could, just running https on the standard port 80. Even the guys at Apache could make SSL default on port 80. If all the web was SSL’d this way, eavesdroppers would have some harsh times then. And that would be matter of UPGRADING the browser software and the server software which would take the SAME effort and money as a normal patch.. so I don’t see why anyone is doing this. Maybe because someone wants things to be like THIS, for some other purpose. who knows.

  19. Sasha Says:

    It remains a difficult thing to tackle, I think banks understand the issues well enough by now but take their losses anyway. Credit-card issuers are a good example of this. Security is fragile and you can do only so much. Albeit, social engineering will simply prevail in most cases. It’s a dim view, yes, but I guess that’s all we have.

  20. Sasha Says:

    @MrAnderson

    Well, it’s an idea most people thought about. But the problem is that it takes too much cryptographic resources to push everything over TLS. IPv6 is a better step in the right direction, But I think we won’t see any changes for a long time unless computation gets way more efficient.

  21. Sasha Says:

    But after reading this:

    https://www.chase.com/ccp/index.jsp?pg_name=ccpmapp/shared/assets/page/Crypto_standard

    I have to take my previous statement back.

    We currently support the following browsers:

    * Internet Explorer® 6.0 and higher

  22. pope Says:

    not only does sslstrip put your notes into action, also does Moxie’s talk about sslstrip (on the same page) focus on these scenarios