(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). > 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 TLD 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 list, I'd say on the balance of probability they'd trust the site, 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?
Bug 1663270 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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). > 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 TLD 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?
(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?