1663270 - Firefox lockwise proposes to use a password from a different subdomain

Status: NEW

(Toolkit :: Password Manager, enhancement, P4)

Description

[info]

Attachment: LockWise_screenshots.zip

I discovered this when visiting the login page on mail.ows.be: the username stored for spam.ows.be got proposed while those two systems are not on the same IP address. Please see attached ZIP file with screenshots.

I see the following scenarios where this could lead to credential theft when the second URL (mail.ows.be in my above example) is used in a phishing attack when sending victims links to:

• Domains where creation of A-records can be done by anyone (e.g. credentials for myapp.azurewebsites.net would get suggested for phishingattack.azurewebsites.net).
• An A-record pointing to the IP address of a compromised server.
• An A-record pointing to an IP address that has moved to someone else's control (end user is likely to trust when the domain looks familiar)
• An A-record in the public DNS of the parent domain, pointing to an RFC1918 address while the victim is connected to an attacker-controlled network, (and of course chose to use a public DNS instead of the DHCP-assigned one; when relying on an attacker controlled DNS server, this attack would become even easier).

What is the reason for this behaviour of Lockwise to ignore the subdomain and propose filling credentials for all subdomains?
Could it be that this behaviour is only triggered because
a) the e-mail address is on the same domain as the parent domain of the two websites involved?
b) The IP addresses of both domain are in the same subnet ?

Best regards and thanks for looking into this,
Georges Bolssens
[e-mail]

Comment 1

[info]

The credential compromise would not even require actual submission of the credentials. Using Javascript you could capture the values of the input fields and send them to a POST endpoint on the same domain after they've been populated. This HTTP request would, due to being on the attacker-controlled domain, not be considered cross-origin so I'm assuming the same-origin-policy would not block that request?

Comment 2

[:Gijs (out for now; he/him)]

(In reply to info from comment #0)

This is all part of a feature, not a bug per se - see bug 589628. bug 1601558 tracks figuring out cases where there are too many logins to usefully display in this way, and if you find it a hindrance rather than a help you can turn it off in about:config using the pref signon.includeOtherSubdomainsInLookup.

I see the following scenarios where this could lead to credential theft when the second URL (mail.ows.be in my above example) is used in a phishing attack when sending victims links to:

• Domains where creation of A-records can be done by anyone (e.g. credentials for myapp.azurewebsites.net would get suggested for phishingattack.azurewebsites.net).

Have you verified that this actually happens for such domains? I would expect it not to; I haven't written or reviewed the code in question but I'd expect it to rely on our internal API which uses Firefox's copy of the public suffix list, which is designed to deal with exactly this type of issue (see also: cookies, local storage access, use of document.domain to achieve same-originness, etc. etc.), along with anomalies such as foo.com vs foo.co.uk and so on.

• An A-record pointing to the IP address of a compromised server.
• An A-record pointing to an IP address that has moved to someone else's control (end user is likely to trust when the domain looks familiar)
• An A-record in the public DNS of the parent domain, pointing to an RFC1918 address while the victim is connected to an attacker-controlled network, (and of course chose to use a public DNS instead of the DHCP-assigned one; when relying on an attacker controlled DNS server, this attack would become even easier).

For the last 3 suggestions, your assumption is just as likely to happen on the actual target domain, surely? That is, if I am the legitimate owner of foo.com, why would my A records for a.foo.com be any easier to compromise than A records for b.foo.com, or, for that matter, foo.com? Also, if an attacker compromised a.foo.com, and provided a spoof page, surely they would already have the possibility of obtaining the "real" a.foo.com credentials if not shared with b.foo.com, which would be an issue in and of itself? And if you, the user, know that credentials aren't the same between a.foo.com and b.foo.com, why would you use the credentials for one when accessing the other, with or without the A record compromise, and with or without the Firefox UI which explicitly calls out the different subdomain-ness of the credentials ?

Comment 3

[info]

Hello Gijs,

Finally got to make some time to look into this

I see the following scenarios where this could lead to credential theft when the second URL
(mail.ows.be in my above example) is used in a phishing attack when sending victims links to:
Domains where creation of A-records can be done by anyone (e.g. credentials for myapp.azurewebsites.net would get suggested for
phishingattack.azurewebsites.net).

Have you verified that this actually happens for such domains?

I just created two App Services on Azure (https://f523b2aa.azurewebsites.net/ and https://53b24cbb.azurewebsites.net/ ) and made sure that they are hosted in different Azure regions so the IP addresses are in a different netblock. It's indeed the case that Lockwise's "subdomain-bleed-over" of passwords doesn't happen there, supporting your hunch that the PSL is being used to mitigate this. I was not aware that such a project existed so thanks for making me aware of that. I am however going to make a suggestion to the maintainers of the PSL to add azurestaticapps.net, which is a new Azure feature in preview for easily hosting static HTML sites (https://azure.microsoft.com/en-us/services/app-service/static/). Also there, when creating such a Static Web App, a subdomain is created underneath azurestaticapps.net, but this domain is not yet in the PSL.

For the last 3 suggestions, your assumption is just as likely to happen on the actual target domain, surely?

To be clear, I'm talking about compromise of the server that the A-record points to; not compromise of the DNS-server where an attacker would be equally capable of changing the IP of any A-record to a server they control. The 3rd scenario for a 10.X.X.X.X or 192.168.X.X where the attacker is the DNS server, I agree would be more rare and would require insider knowledge. Not impossible, but still one to take into remote account.

Under that context and from my experience as a penetration tester, I'd beg to differ that every subdomain under one registered domain would be equally easy to breach. In a few of my client engagements, I have come across e.g. test.customer.com that I could breach as opposed to crm.customer.com which was a properly hardened production system. When post-compromise launching a phishing attack to the employees of customer.com leading them to test.customer.com (*) under the guise of "please help us test the new CRM", Lockwise by default proposes their credentials for crm.customer.com. Clicking auto-fill is done very eagerly and after that the credential compromise happens as a direct consequense of accepting Lockwise's proposal before the user submits the form, increasing my chances as an attacker of getting more user credentials. This was the main point I wanted to drive home as the cross-sub-domain-credential-proposal-feature of Lockwise takes away a barrier of a user to actually submit the login form, making that one click suggested by Lockwise the compromising action. Agreed, a portion of targeted victims will not have this hesitation and submit the form anyway, but my proposal would be to disable this proposal-behaviour by default altogether to avoid risking this scenario being facilitated by Lockwise.

(*) Awareness trainings tell users to pay close attention to the domain and not so much the subdomain.

And if you, the user, know that credentials aren't the same between a.foo.com and b.foo.com, why would you use the credentials for one when accessing the other, with or without the A record compromise, and with or without the Firefox UI which explicitly calls out the different subdomain-ness of the credentials ?

I have three thoughts on that:

a) From my experience in teaching cybersecurity awareness sessions to lay people, I've come to learn that most internet users don't have any idea which passwords on which sites are different or similar. They use a password manager like Lockwise specifically to not have to remember that. Again to my previous point where accepting the proposal of Lockwise in itself triggers the exploit, the end user would not even be given the opportunity to second-guess that fact and the credential compromise would have already happened.

b) if the assumption is that the password on b.foo.com is different from a.foo.com, then why is Lockwise's default behaviour to assume the opposite? (i.e. that all subdomains of .foo.com would have the same credentials), leading to users picking similar credentials across subdomains for the sake of ease-of-use? This is a point also made in comment Nr. 10 of bug #1601558 that you referenced:

The current behaviour is a misfeature that seems to be actively promoting the sharing of passwords between different logins.
(https://bugzilla.mozilla.org/show_bug.cgi?id=1601558#c10)

c)

if you find it a hindrance rather than a help you can turn it off in about:config using the pref signon.includeOtherSubdomainsInLookup

My distinction is not hindrance (on) vs. help (off). My distinction is risk mitigation (off) vs. facilitating specific attack scenarios (on).

My proposal would be to have this setting be off by default and have a clear tickbox in about:logins that explains the risk of users turning it on. This setting would ideally be on a per-domain-basis instead of it now being globally, so the different use cases weighed in bug #1601558 can still be supported.

Hoping that this suggestion will help make the internet safer for lay people, I'm looking forward to your response. Having those people make use of a password manager definitely increases their online safety and I think that otherwise Lockwise is a great addition to Firefox, while at the same time I do feel that, by considering this change, it will be a bit more secure when dealing with an attacker-scenario in mind.

Best regards and respectfully yours,
Georges Bolssens

Comment 4

[:Gijs (out for now; he/him)]

(In reply to info from comment #3)

I am however going to make a suggestion to the maintainers of the PSL to add azurestaticapps.net, which is a new Azure feature in preview for easily hosting static HTML sites (https://azure.microsoft.com/en-us/services/app-service/static/). Also there, when creating such a Static Web App, a subdomain is created underneath azurestaticapps.net, but this domain is not yet in the PSL.

Oof. Yeah, that's going to be a good idea regardless - as you might have gathered from my earlier comments, there are other security reasons that they probably want that, irrespective of what happens here... (e.g. the ability of myapp.azurestaticapps.net to set cookies that apply to all of azurestaticapps.net!)

Under that context and from my experience as a penetration tester, I'd beg to differ that every subdomain under one registered domain would be equally easy to breach.

OK, sure, I wouldn't dispute this - I was commenting on the likelihood of compromising one DNS record but not another (for the same TLD+1).

In a few of my client engagements, I have come across e.g. test.customer.com that I could breach as opposed to crm.customer.com which was a properly hardened production system. When post-compromise launching a phishing attack to the employees of customer.com leading them to test.customer.com (*) under the guise of "please help us test the new CRM", Lockwise by default proposes their credentials for crm.customer.com.

OK. I can see the argument that this makes things slightly worse. I don't know if this is severe enough to consider this by itself a security bug, especially considering:

• it'll be easier (even without lockwise) to leverage compromise of foo.corp.com into bar.corp.com purely because the e-TLD+1 is same-origin; and
• if your main test.customer.com site just has some text saying "please log in with your crm.customer.com credentials", and the user trusted the email enough to open the site, I'd say on the balance of probability they'd trust the site's comments, too, especially if it shares a toplevel domain with the "real" domain anyway!

Mozilla use allizom.org for our test/pre-production sites for these and other reasons...

Dan/Freddy, thoughts on the severity here?

Clicking auto-fill is done very eagerly and after that the credential compromise happens as a direct consequense of accepting Lockwise's proposal before the user submits the form,

Yeah, but this is always true - if the user starts typing the password and then changes their mind, the same thing applies - an attacker that can execute script on the login form can always steal passwords before the submit button is clicked. I don't think this part should influence our decision.

I have three thoughts on that:

a) From my experience in teaching cybersecurity awareness sessions to lay people, I've come to learn that most internet users don't have any idea which passwords on which sites are different or similar. They use a password manager like Lockwise specifically to not have to remember that. Again to my previous point where accepting the proposal of Lockwise in itself triggers the exploit, the end user would not even be given the opportunity to second-guess that fact and the credential compromise would have already happened.

Yeah, but the problem is that foo.corp.com and bar.corp.com are already not fully separated - if I compromise foo.corp.com I can already get access to anything shared with all of corp.com which will often be bad enough. The lockwise UI is just one artifact of this - the controlling entity is supposed to be the same. When it's not, the potential for password leakage is just one of the many, many problems you have.

b) if the assumption is that the password on b.foo.com is different from a.foo.com,

No, the assumption is that if you're using www.publicwebsite.com and they move their login form to login.publicwebsite.com but uses the same credentials, you want the autofill solution to deal with that, rather than having users have to go through an "I forgot my password" flow.

I'd argue that this case is significantly more common/likely than the compromised subdomain, in terms of how often it occurs over all our users and all websites.

Your attack assumes the passwords are different and that convincing the user to enter their www.publicwebsite.com username/password combo into compromised.publicwebsite.com is an issue. I'm sure this is not unheard of, though on the other hand my impression is more and more places are switching to SSO which sort of goes in the opposite direction...

c)

if you find it a hindrance rather than a help you can turn it off in about:config using the pref signon.includeOtherSubdomainsInLookup

My distinction is not hindrance (on) vs. help (off). My distinction is risk mitigation (off) vs. facilitating specific attack scenarios (on).

My proposal would be to have this setting be off by default and have a clear tickbox in about:logins that explains the risk of users turning it on. This setting would ideally be on a per-domain-basis instead of it now being globally, so the different use cases weighed in bug #1601558 can still be supported.

I don't think this suggestion aligns with the practical upshot of the option for most users' and websites' usecases. On corporate deploys where the cost/benefit balance is different, the company in question can turn this off via the pref. It looks like https://phabricator.services.mozilla.com/D87447 didn't include signon prefs into ones subject to enterprise policy (though there are legacy mechanisms to do the same thing), perhaps we should add that in a separate (non-security bug). Mike, thoughts?

Comment 5

[:Gijs (out for now; he/him)]

(In reply to :Gijs (he/him) from comment #4)

(In reply to info from comment #3)

I am however going to make a suggestion to the maintainers of the PSL to add azurestaticapps.net, which is a new Azure feature in preview for easily hosting static HTML sites (https://azure.microsoft.com/en-us/services/app-service/static/). Also there, when creating such a Static Web App, a subdomain is created underneath azurestaticapps.net, but this domain is not yet in the PSL.

Oof. Yeah, that's going to be a good idea regardless - as you might have gathered from my earlier comments, there are other security reasons that they probably want that, irrespective of what happens here... (e.g. the ability of myapp.azurestaticapps.net to set cookies that apply to all of azurestaticapps.net!)

And to be clear, assuming MS controls azurestaticapps.net, I think you should report this to MS and they might want to treat that on its own as a security issue...

Comment 6

[info]

Thanks for your elaborate response, Gijs.

Even if not filed as a security bug (of in the end not being taken into consideration at all), I'm already happy that it is being looked at by you and your colleagues. I guess a password manager is one of those that has so many unique use cases that it's hard to come up with one single set of defaults that works for everyone.

I have differing views on how likely or inconvenient specific things are

Clicking auto-fill is done very eagerly and after that the credential compromise happens as a direct consequense of accepting Lockwise's proposal before the user submits the form,
Yeah, but this is always true - if the user starts typing the password and then changes their mind, the same thing applies - an attacker that can execute script on the login form can always steal passwords before the submit button is clicked. I don't think this part should influence our decision.

If this happens when they start typing their password, the attacker only has part of their password, but you're right that most end users will just happily type their entire password and submit the form anyway, which weakens the increased risk attack scenario I'm envisioning.

a) From my experience in teaching cybersecurity awareness sessions to lay people, I've come to learn that most internet users don't have any idea which passwords on which sites are different or similar. They use a password manager like Lockwise specifically to not have to remember that. Again to my previous point where accepting the proposal of Lockwise in itself triggers the exploit, the end user would not even be given the opportunity to second-guess that fact and the credential compromise would have already happened.

Yeah, but the problem is that foo.corp.com and bar.corp.com are already not fully separated - if I compromise foo.corp.com I can already get access to anything shared with all of corp.com which will often be bad enough.

"anything" is assuming that all cookies are set to Domain=.corp.com, which would be a bad practise from the developer's end; then again: we're talking about a company that has a breach in an old unpatched system that should not be live in the first place so I agree that the two are more likely to coincide. In the bigger picture, depending on what's on that system it may well be more feasible for the attacker just to crypto-lock it (just to illustrate that all bets are off at that point), which is definitely not a problem for Lockwise to solve anymore :).

b) if the assumption is that the password on b.foo.com is different from a.foo.com,
No, the assumption is that if you're using www.publicwebsite.com and they move their login form to login.publicwebsite.com but uses the same credentials, you want the autofill solution to deal with that, rather than having users have to go through an "I forgot my password" flow.
Which forces them to change their password :D.
No, j/k ; I see your point where you don't want to make a password manager too tedious to use.

I'd argue that this case is significantly more common/likely than the compromised subdomain, in terms of how often it occurs over all our users and all websites.

While cycling I'm much less likely to get hit by a car than by a raindrop, but the severity of the event is quite different (even though arriving at work soaking wet is at least as inconvenient as having to change my password, I'd rather still arrive at work than at a hospital ;-) ).

And to be clear, assuming MS controls azurestaticapps.net, I think you should report this to MS and they might want to treat that on its own as a security issue...

I realized this when I was reading the submission guidelines for the PSL and notified the Azure team on Twitter. They responded 10' later that they'll be looking into it.

Have a great day and thanks again!

Warm regards,
Georges

Comment 7

[Frederik Braun [:freddy]]

I'd say this is sec-low.

Comment 8

[Mike Kaply [:mkaply]]

Definitely would make sense to add signon.* to the policy list. I opened bug 1664834

Comment 9

[Sam Foster [:sfoster] (he/him)]

I've read through the discussion and I don't see anything actionable here for the password manager component. Is there some defect or feature enhancement we should be considering, or can I close this out?

Comment 10

[:Gijs (out for now; he/him)]

(In reply to Sam Foster [:sfoster] (he/him) from comment #9)

I've read through the discussion and I don't see anything actionable here for the password manager component. Is there some defect or feature enhancement we should be considering, or can I close this out?

Well, from Georges' comments, clearly they feel we should turn off other-subdomain autocomplete suggestions by default.

I don't think doing so is the right trade-off.

It'd be useful to consider if there are any heuristics we could use to distinguish the "these are deliberately different passwords" case from the "there is only one password for the entire eTLD+1" case. We could choose to not offer the other subdomain completion (by default) if there are multiple, distinct passwords saved, for different subdomains, with the same username? As that'd indicate that the site in question has different passwords for different subdomains... Does that sound like something we could do without too much negative fallout?

Comment 11

[Sam Foster [:sfoster] (he/him)]

(In reply to :Gijs (he/him) from comment #10)

Well, from Georges' comments, clearly they feel we should turn off other-subdomain autocomplete suggestions by default.
I don't think doing so is the right trade-off.

Agreed, we have had long discussions with pros and cons voiced and argued on this issue. I'm not saying we would never change this decision, but this bug doesn't present new arguments that have not already been weighed.

It'd be useful to consider if there are any heuristics we could use to distinguish the "these are deliberately different passwords" case from the "there is only one password for the entire eTLD+1" case. We could choose to not offer the other subdomain completion (by default) if there are multiple, distinct passwords saved, for different subdomains, with the same username? As that'd indicate that the site in question has different passwords for different subdomains... Does that sound like something we could do without too much negative fallout?

I think its certainly something we could investigate, so worth keeping the bug on file for. I don't think this needs to be a closed/secure bug though? (And I do not have the ability to change that.) I'll take a first stab at severity/priority.

Comment 12

[Daniel Veditz [:dveditz]]

We should keep this bug hidden for now because of the azurestaticapps.net /PSL situation, but it does not need to be a hidden security bug about the password manager issue. It's a fruitful discussion about the design tradeoffs, but it's been discussed in public bugs elsewhere so hiding it doesn't exactly protect users. For most of Firefox history--before Firefox, even--Mozilla has leaned to the "an origin is an origin, better safe than sorry" side. And from early on (see bug 92966 from 2001) this caused usability problems on real-world multi-host sites. After a lot of discussion over a long time the password manager team has decided that the user benefit outweighs the phishing risk.

They might be wrong! But I'm not convinced a couple of folks arguing in a private bug are going to come to a better answer, and a public discussion may help. After being a firm "origin is origin, 'site' is a trap" guy for years I'm a bit on the fence myself. I've personally run into enough of the broken type sites where I've had to manually find my password for foo.domain.example and paste it into bar.domain.example that I'd probably fall victim to a reasonably convincing compromised-sibling-domain phishing attempt with or without this use new UX.

It does seem like the drop-down should make a better distinction between the password for the exact origin and passwords that aren't. Color and shading, perhaps?

Comment 13

[info]

azurestaticapps.net is still not on the PSL. Nudged @nthonyChu at MS.

Comment 14

[Daniel Veditz [:dveditz]]

Kudos to the reporter and Anthony at MS for the above. azurestaticapps.net was added to the Firefox copy of the PSL just a couple days later (on 2020-10-29) and had to have been added to the upstream list before then.