*Hello Everyone: I am Eric Chen from CMU. We are working on a paper that is closely related to the topic of this discussion, so I thought I should bring it up. Our paper describes an attack that automatically crawls the password manager of an user inside an unsecure wireless network. The attack can be launched as follows:
1. User visits “any” unencrypted page inside a wireless network (e.g., it can be their home page http://www.google.com) <about:blank> 2. Attacker use ARP spoofing attack to impersonate the gateway to intercept traffic. 3. Attacker injects 1000 (an arbitrary number) invisible iframes, each points to a different HTTP login page of the Alexa top 1000 sites (i.e., http://facebook.com, <about:blank> http://twitter.com). There are simple tricks to make these iframes invisible to normal users, but for the sake of simplicity, I won’t discuss them here. 4. Inside each of these iframes, attacker injects a username field, a password field, and a script to read the autofilled password. 5. Browser autofills password for each of the 1000 sites, attacker reads it, and send it back. What’s interesting about this attack is that it’s very stealthy (virtually undetectable), fast, and does not require the user to visit the vulnerable page. Furthermore, even if the website moves all login forms to HTTPS pages, the old passwords are still vulnerable. We are also interested in a defense for this. The defense that we came up with is actually very similar to proposal 1) and 3). Furthermore, for sites that do not use HSTS, we were planning to check if the form target is a HTTPS page, if it is, then we redirect the user to the HTTPS version of the same page (if it exists). As a side note, this automatic attack does not work for IE and Opera, because these two password managers require the user to initiate the autofilling process (by entering the first character into the username box). * On Wed, Apr 11, 2012 at 9:47 AM, Ian Melven <[email protected]> wrote: > > Hi, > > I agree with Gerv that #1 seems good. > > #2, i have a slight concern about history leakage but don't think > this is an issue for correctly set up STS sites, and this isn't > an issue with the actual proposal here - which seems like a good > addition to #1 > > I also agree with Gerv that #3 definitely could confuse users, > assuming the site still allows http (which, it could be argued, > would be an incorrectly set up site). > > #5 definitely seems good - i assume 16 months is arbitrary :) > > #6 and #7 seem less practical to me. > > slightly related : > https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords > this won't help in the case of autofill though > > thanks ! > ian > > > ----- Original Message ----- > From: "Jesse Ruderman" <[email protected]> > To: [email protected] > Sent: Wednesday, April 11, 2012 12:54:53 AM > Subject: stealing saved passwords > > A wifi MITM attacker can steal all the passwords you have saved on > http sites, by sending you to fake versions of each site and watching > what the browser fills into the form. > > You're safe iff you initially saved the password from an https page, > or if the site now uses STS, or maybe if you're extremely careful to > never open any http pages while connected to untrusted networks. > > I have some ideas for mitigating this risk. > > 1) If a site sends an STS header, and the user has any data (cookies, > passwords, etc) that are not https-only, immediately mark that data as > https-only. (This helps if a site uses STS, but the user's privacy > settings cause the password storage to outlive the STS storage.) > > 2) When clearing history, retain the STS bit if any other data > associated with the site is retained. For example, in the common case > of clearing all history other than passwords, retain the STS bits for > sites that have passwords stored. (This accomplishes roughly the same > thing as #1.) > > 3) If you have a password stored for http, and you log into the same > site using https, move the password to https-only. (This helps if a > site moves from http to https, but does not set STS.) > > 4) If an identical password is stored for both any http site and any > https site, stop autofilling it on the http site. Instead, provide a > way for users to instruct the browser to fill it in (e.g. an infobar). > > 5) If an identical password is stored for both any http site and any > https site, and it is not used on the http site for 16 months, expire > the http version. (This helps in cases where the hostname has changed, > e.g. from mail.google.com to www.google.com, and the security level > has also changed.) > > 6) When connected to an untrusted wireless network, don't fill in > passwords. > > 7) When connected to an untrusted wireless network, refuse to make any > insecure connections. If the user really wants to open an insecure > search result, they can open it in a separate browsing session. > > Which of these seem practical and worth implementing? > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > -- -Eric _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
