Bitwarden leaks passwords to other subdomains(twitter.com)
twitter.com
Bitwarden leaks passwords to other subdomains
https://twitter.com/RitzmannMarkus/status/1307614248835731456
72 comments
Ryan Sleevi suggests (perhaps that's putting it too mildly) that further reliance on the PSL is a bad idea:
https://github.com/sleevi/psl-problems and https://news.ycombinator.com/item?id=24441942
His recommendation is to as much as possible use the Same Origin Policy or if you must, a slightly weakened variant like ignoring port numbers.
I suspect I'll make another comment elsewhere in this discussion that says more about the problems with that.
https://github.com/sleevi/psl-problems and https://news.ycombinator.com/item?id=24441942
His recommendation is to as much as possible use the Same Origin Policy or if you must, a slightly weakened variant like ignoring port numbers.
I suspect I'll make another comment elsewhere in this discussion that says more about the problems with that.
Another relevant read is the ICANN's research on the same: https://research.google/pubs/pub43821/
Title: SSAC Advisory on the Use of Static TLD / Suffix Lists
Ultimately, it boils down to there not being any decent alternative. This is exactly the kind of hard problem that IETF should be tacking.
Title: SSAC Advisory on the Use of Static TLD / Suffix Lists
Ultimately, it boils down to there not being any decent alternative. This is exactly the kind of hard problem that IETF should be tacking.
I am shocked how broad the list has grown. A few years ago it only contained the iana domains now there are many domains for cloud services etc.
This seems to be an inevitable outcome as ICANN has sold out. It should have been an international non-profit once the significance of domain names became clear.
ICANN is a mess, look at the pricing of new TLD like .rich. It's all joke because it's not a neutral entity with proper peer pressures.
ICANN is one of the internet's failure.
ICANN is one of the internet's failure.
How does this have anything to do with ICANN selling out?
TLDs proliferated which contributes to weaknesses like this one in BitWarden.
TLD proliferation has nothing to do with this problem though.
As far as I can tell Bitwarden is using that and pulling that info here:
https://github.com/bitwarden/server/blob/0f1efdd18b879ccdf41...
https://github.com/bitwarden/server/blob/0f1efdd18b879ccdf41...
Looks like user error. The domain matching needs to be set if you don’t want it to work on sub domains. The fact Bitwarden does this by default is a wonderful feature. So I don’t consider it leaking. Besides if you don’t trust a sub domain you shouldn’t trust the root domain.
As Mozilla always says: Default Settings Matter. And here it is even, that Bitwarden ignores my own settings. Bitwarden ignores that Auto-Fill is switched off.
I agree with most of this, but it seems one of the main issues is that it sends it even if autofill is off. I could easily imagine someone overlooking the default setting and inadvertently revealing their password.
Also, on what basis is your last statement? There are plenty of scenarios where a subdomain is managed different people, or even different companies. Why should you not trust the root domain if you don't trust the subdomain?
Also, on what basis is your last statement? There are plenty of scenarios where a subdomain is managed different people, or even different companies. Why should you not trust the root domain if you don't trust the subdomain?
I just re-read the thread and realise I completely missed the bit where auto-fill is sent when turned off. That definitely had to be a bug!
In regards to the last statement. It’s much rarer now-days for a sub domain site to be owned outright by someone else where they have logs or a deployed website to capture this information.
In fact I honestly cannot think of a subdomain where I can upload my own code to. All the sub domains I can think of are just for multi tenant systems so you have to trust the root domain.
In regards to the last statement. It’s much rarer now-days for a sub domain site to be owned outright by someone else where they have logs or a deployed website to capture this information.
In fact I honestly cannot think of a subdomain where I can upload my own code to. All the sub domains I can think of are just for multi tenant systems so you have to trust the root domain.
Dynamic DNS hosts could have thousands of subdomains under an individual domain, can be registered for free, and those credentials could get an attacker right into people's home networks. An attacker could hide a bunch of iframes in a page and cover lots of bases in one go.
Github Pages, Netlify, Surge. Wordpress hosts. All of these have very different people controlling the code on the subdomain, than on the root. The root in many cases may actually be trustworthy, but there's no reason to send them credentials that belong with the subdomain.
Correct, one example of that subdomain is; ca.gov domain is main domain of California Government, and each department of government have their own sub domain here, often at many levels, dmv.ca.gov, CalCareers.ca.gov, calconnect.ca.gov, dgs.ca.gov. All of these 4 have their own account options & passwords. Chrome displays all options on all domains, but on EXACT match, it just shows username, & shows other sub-domains under username, the ones which doesn't match with current dub domain.
Isn't that why sites like GitHub Pages moved to GitHub.io.
Any popular service at this point wouldn't be allowing user content on their main domain.
Any popular service at this point wouldn't be allowing user content on their main domain.
Not only that, but github.io is on the Public Suffix List, which is designed for this purpose. Any site that allows users to run servers or host arbitrary HTML/JS on a subdomain should ensure that the parent domain is on the Public Suffix List, which ensures that one user can't even attack another. (The other problem the Public Suffix List solves is that "foo.co.uk" and "bar.co.uk" shouldn't be treated like "foo.example.com" and "bar.example.com", even though they have the same number of components.)
Interesting - I'd heard about the reasoning for github.io being separate from github.com, to deal with untrusted subdomains. But I didn't know that anyone could register on the Public Suffix List.
The submission process is done via a pull request, described here:
https://github.com/publicsuffix/list/wiki/Guidelines
The submission process is done via a pull request, described here:
https://github.com/publicsuffix/list/wiki/Guidelines
A common practice (at least in the past) was universities that gave subdomains to students and student groups. The result is subdomains like studygroups and studentunions.
In term of identity, students are part of an university, but in term of security, students are not trusted as much as the university itself. In term of technology it is even possible that the subdomain sits at its own name servers.
Even for some of the largest websites on the world like google, I honestly doubt they consider subdomains to be as trusted as root domains. Are every single experimental project at google with its own subdomain as trusted and secure as root?
In term of identity, students are part of an university, but in term of security, students are not trusted as much as the university itself. In term of technology it is even possible that the subdomain sits at its own name servers.
Even for some of the largest websites on the world like google, I honestly doubt they consider subdomains to be as trusted as root domains. Are every single experimental project at google with its own subdomain as trusted and secure as root?
I've had this problem. I used one of my student domains to do research for a course, which required generating a new username and password. Bitwarden's default automagically filled in my uni credentials, which would give access to stuff like VPNs, grades, the whole deal!
I've now configured the domain matching correctly, but the default has burned me more often than I'd like.
I've now configured the domain matching correctly, but the default has burned me more often than I'd like.
There was a long time where the only way to watch ExoSquad post-cancellation, unless you taped it, was to download it from a site hosted on someone's subdomain on a university domain.
Universities who do this should make sure that .example.edu (or perhaps .students.example.edu or .sites.example.edu or something) is on the Public Suffix List. (I'm hoping Bitwarden defines "base domain" as "one level past a public suffix"; if not, that's a serious bug.)
Re trust - in practice, yes, they are, because anything.google.com can read google.com cookies. It's a pretty minor expense for me, a private individual, to register a new domain name: it's an even more minor expense for Google, even apart from the fact that they own .dev and .google and others.
Re trust - in practice, yes, they are, because anything.google.com can read google.com cookies. It's a pretty minor expense for me, a private individual, to register a new domain name: it's an even more minor expense for Google, even apart from the fact that they own .dev and .google and others.
IMHO the default HTTP trust model where a domain implicitly trusts its subdomains is at fault here, when the logical solution would be to remove the trust altogether or at least make it explicit both ways.
With regard to Bitwarden's default behavior to match the whole domain, it's irritating even when it's not a risk. We manage a ton of our systems under the same domain to allow a single 2FA signon before even giving access to the individual services and all the credentials have to be manually set as host-only or they will be autofilled for every other system we're managing.
With regard to Bitwarden's default behavior to match the whole domain, it's irritating even when it's not a risk. We manage a ton of our systems under the same domain to allow a single 2FA signon before even giving access to the individual services and all the credentials have to be manually set as host-only or they will be autofilled for every other system we're managing.
It's also a user error to reuse passwords, or to 'rotate' them in a predictable manner, or to fill in their password on a phishing site, or to install a password manager which doesn't have secure defaults or even ignore a security setting.
I disagree. The default for a password manager should be the most secure, with additional features and behavior only being enabled after the user has had at least the chance to make an informed decision.
The most secure is not the most restrictive. A password manager extension has to work. If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure".
Sure, it should work reliably, but it also shouldn't have unexpected dangerous behavior like OP's complaint that the average user is not aware of.
It could ship with good defaults and at some point, during setup, some introduction or when relevant conditions are met, ask the user if they want to enable that feature/behavior while giving more information about what it does and potential weaknesses. It doesn't have to be disabled forever or hidden behind some obscure feature flag.
It could ship with good defaults and at some point, during setup, some introduction or when relevant conditions are met, ask the user if they want to enable that feature/behavior while giving more information about what it does and potential weaknesses. It doesn't have to be disabled forever or hidden behind some obscure feature flag.
> If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure".
Why not?
Why not?
Because one of the security functions of a browser extension (as demonstrated by this very issue) is to ensure that a password for one site only goes to the same site, and not to a convincing-to-a-human phishing site. A browser extension that you can rely on to fill in your password is therefore better for your security than one where you get in the habit of deciding you know better than it and end up copying and pasting passwords and making judgments yourself.
Input just only for specified (registered) domain name is good for security. If you often use copy and paste, you may not notice you're inputting on phishing site that uses different domain name.
[deleted]
Edited: The original example I had here is wrong because of a mismatched TLD.
From their own description of the technology (I am not a Bitwarden user) with Bitwarden's default behaviour if you have credentials for the EXA Metal Pole Europe secure website https://example.co.uk/ it will provide those credentials automatically, without prompting, to the completely different, unsecured site http://cat-jokes.example.co.uk/ if any requests to that site are made.
Notice that as an on path bad guy I don't need to own example.co.uk or cat-jokes.example.co.uk, I just need to persuade your browser (e.g. with an image link) that it wants to fetch resources from http://cat-jokes.example.co.uk/ for which it needs to do Basic auth and Bitwarden will write your example.co.uk credentials to the wire in plaintext. YSOABII.
I don't think this obeys the principle of least surprise. I don't think it's a secure behaviour to have at all even for fairly experienced users, and I definitely don't think it should be the default.
The safe default is Same Origin Policy which is similar to their "same host" but a bit different. Others have recommended the PSL, and that's certainly less awful than what Bitwarden does now, but it's not good, I certainly wouldn't want Bitwarden to switch to the PSL and then just figure job done and walk away.
From their own description of the technology (I am not a Bitwarden user) with Bitwarden's default behaviour if you have credentials for the EXA Metal Pole Europe secure website https://example.co.uk/ it will provide those credentials automatically, without prompting, to the completely different, unsecured site http://cat-jokes.example.co.uk/ if any requests to that site are made.
Notice that as an on path bad guy I don't need to own example.co.uk or cat-jokes.example.co.uk, I just need to persuade your browser (e.g. with an image link) that it wants to fetch resources from http://cat-jokes.example.co.uk/ for which it needs to do Basic auth and Bitwarden will write your example.co.uk credentials to the wire in plaintext. YSOABII.
I don't think this obeys the principle of least surprise. I don't think it's a secure behaviour to have at all even for fairly experienced users, and I definitely don't think it should be the default.
The safe default is Same Origin Policy which is similar to their "same host" but a bit different. Others have recommended the PSL, and that's certainly less awful than what Bitwarden does now, but it's not good, I certainly wouldn't want Bitwarden to switch to the PSL and then just figure job done and walk away.
If you’re hosting a static website on cat-jokes... then any requests made are going to the owners of example.co.uk not to whoever has cat-jokes...
It only works if the sub domain grants you some sort of usage on that sub domain. But how many hosts are like that these days?!?
One example given is GitHub, but it doesn’t allow you to host serverside code. It’s purely static.
Wordpress maybe? But I’ve never used hosted Wordpress so I donno what access you get.
It only works if the sub domain grants you some sort of usage on that sub domain. But how many hosts are like that these days?!?
One example given is GitHub, but it doesn’t allow you to host serverside code. It’s purely static.
Wordpress maybe? But I’ve never used hosted Wordpress so I donno what access you get.
The on path attacker isn't hosting the website (static or otherwise) on http://cat-jokes.example.co.uk/ indeed with more work the name needn't even "exist" let alone a site.
Let's suppose I'm an on path adversary, you're my victim and example.co.uk are a passive third party.
You have credentials for https://example.co.uk/ stored in Bitwarden with default settings
I inject any URL into any flow that will cause your browser to try to fetch something from http://cat-jokes.example.co.uk/ maybe it's an image URL, or a frame.
But that's an HTTP site, so I can intervene when your browser connects and impersonate as cat-jokes.example.co.uk to ask for Basic auth credentials, Bitwarden cheerfully fills them out automatically with your credentials for the secure site https://example.co.uk/ and sends them plaintext so now I get your credentials.
Nothing looks out of place to you, maybe an image or frame was slow to load, but certainly no alerts, no indication anything weird happened.
Let's suppose I'm an on path adversary, you're my victim and example.co.uk are a passive third party.
You have credentials for https://example.co.uk/ stored in Bitwarden with default settings
I inject any URL into any flow that will cause your browser to try to fetch something from http://cat-jokes.example.co.uk/ maybe it's an image URL, or a frame.
But that's an HTTP site, so I can intervene when your browser connects and impersonate as cat-jokes.example.co.uk to ask for Basic auth credentials, Bitwarden cheerfully fills them out automatically with your credentials for the secure site https://example.co.uk/ and sends them plaintext so now I get your credentials.
Nothing looks out of place to you, maybe an image or frame was slow to load, but certainly no alerts, no indication anything weird happened.
The scope of basic auth credentials is much tighter than even the same origin policy: it also requires the path to match - see section 2.2 of RFC7617 https://tools.ietf.org/html/rfc7617#section-2.2
So Bitwarden’s behaviour is a protocol violation.
So Bitwarden’s behaviour is a protocol violation.
Looks like this is a fix to this posted 30 minutes ago
https://github.com/bitwarden/browser/pull/1397
https://github.com/bitwarden/browser/pull/1397
I think there could be a bug here, but not what the title suggests...
Domain matching is configurable per login, and default also configurable. The default-default is fine (better compatibility). But if people disagree then re-configure the default then deal with the consequences/breakages.
The bug here seems to be auto-completing with auto-fill disabled. That's a bug, and a security bug I'd argue.
PS - Them tagging the bug "enhancement" is also quite wrong. Leaking credentials with auto-fill off is clearly broken at the most basic levels, even if splitting the auto-fill checkbox into two is an "enhancement."
Domain matching is configurable per login, and default also configurable. The default-default is fine (better compatibility). But if people disagree then re-configure the default then deal with the consequences/breakages.
The bug here seems to be auto-completing with auto-fill disabled. That's a bug, and a security bug I'd argue.
PS - Them tagging the bug "enhancement" is also quite wrong. Leaking credentials with auto-fill off is clearly broken at the most basic levels, even if splitting the auto-fill checkbox into two is an "enhancement."
What am I missing here? Why is Bitwarden sending any data on its own at all?
I thought Bitwarden only fills login details in a form when I click on it.
What else is it doing that I am unaware of?
I thought Bitwarden only fills login details in a form when I click on it.
What else is it doing that I am unaware of?
I think the reason is, that Bitwarden can't interact with a BasicAuth dialog because of missing browser APIs. This may be the reason why Bitwarden use this as a workaround: Send the basic auth always automatically (basic auth is only a http header) if a BasicAuth is detected.
I'm using Bitwarden and all of my passwords are long, complex, and unique. Am I at risk? I understand that this is not good, but if my passwords are unique then the only thing that can happen is losing the credentials to the one account that got leaked, right? I don't think my bank's website has an unsecure subdomain that I have to worry about. Should I remove Bitwarden from my browser until this is fixed?
You are at risk if you have credentials stored for any website that allows arbitrary subdomains to be controlled by customers, such as Github pages, Gitlab pages, some ISP and university hosting solutions, etc.
You can ensure the login doesn't leak by changing the match detection settings for your logins. If you've got the match detection for a login set to "base domain" (the default AFAIK), then a login for example.com is also matched for evil.example.com which might be a risk if you get linked or redirected there. If you've got the login configured with "hostname" or "starts with", then you're probably safe.
You're also safe if you've locked your Bitwarden vault. If you want to disable Bitwarden to be sure and you don't want to lose access to your synced data and your settings, just don't unlock the vault (or only unlock it while logging in and lock it immediately after).
I won't personally remove Bitwarden because my most important logins don't allow subdomains to be abused like this. You'll have to make that choice for yourself though.
You can ensure the login doesn't leak by changing the match detection settings for your logins. If you've got the match detection for a login set to "base domain" (the default AFAIK), then a login for example.com is also matched for evil.example.com which might be a risk if you get linked or redirected there. If you've got the login configured with "hostname" or "starts with", then you're probably safe.
You're also safe if you've locked your Bitwarden vault. If you want to disable Bitwarden to be sure and you don't want to lose access to your synced data and your settings, just don't unlock the vault (or only unlock it while logging in and lock it immediately after).
I won't personally remove Bitwarden because my most important logins don't allow subdomains to be abused like this. You'll have to make that choice for yourself though.
Is this true? Are you implying bitwarden doesn't respect the PSL? It seems like it does.
The PSL is not a real solution to this threat, though it does protect a lot of high profile websites; it's a useful tool, but by no means a complete solution to subdomain attacks. With cloud platforms like Azure it's possible for a dangling subdomain to be taken over[1], for example; sure, that's preventable, but it still poses a risk.
As I've said in another comment, many educational facilities also offer subdomains or shared hosting space for students and working groups. An attacker with control over evil.student.university.edu could steal university.edu credentials and use them for all kinds of nasty things like identity theft and blackmail.
Theoretically this could be solved by adding all of these domains to the PSL, but there's more universities in the world than people using PSL so good luck with that. You also risk breaking educational utilities with uninformed listings so you'd need a list from the IT facilitators to be sure about listing something in the PSL. I don't think it's going to happen, and I wouldn't assume the PSL is a waterproof security tool for these kinds of risks.
[1]: https://blog.cystack.net/subdomain-takeover-chapter-two-azur...
As I've said in another comment, many educational facilities also offer subdomains or shared hosting space for students and working groups. An attacker with control over evil.student.university.edu could steal university.edu credentials and use them for all kinds of nasty things like identity theft and blackmail.
Theoretically this could be solved by adding all of these domains to the PSL, but there's more universities in the world than people using PSL so good luck with that. You also risk breaking educational utilities with uninformed listings so you'd need a list from the IT facilitators to be sure about listing something in the PSL. I don't think it's going to happen, and I wouldn't assume the PSL is a waterproof security tool for these kinds of risks.
[1]: https://blog.cystack.net/subdomain-takeover-chapter-two-azur...
I agree completely. However, you listed "Github pages" in your examples which is very well known to be on the PSL.
Things important as banking and email should have 2FA turned on.
If they don't, I'd still say you're reasonably safe given that you're using unique passwords.
If they don't, I'd still say you're reasonably safe given that you're using unique passwords.
I keep the domain match rule as "Starts from" in the global setting not because of this (and I realized it was a good choice more now) but because BitWarden automatically sends basic auth if there is only one match, meaning you never get any prompt to begin with, which is handy but having the default "Base domain" can make the match broader and asks me for basic auth and since an extension can't fill that space probably due to browser extension API, I have to copy / paste which is very tedious.
Are you sure that "start from" is a good idea? Maybe (i don't know) with this google.com.example.com is the same like google.com? So your maybe send your password automatically to a phishing site because of this.
Wow, this is looking real bad...
Checked some entries but thankfully I had slashes after the domain, so those won't be caught.
I suppose "Host" is the most sane option then.
Checked some entries but thankfully I had slashes after the domain, so those won't be caught.
I suppose "Host" is the most sane option then.
I’ve noticed the too-broad matching behavior in the past myself. Password for <production>-admin.okta.com will auto fill for <development>-admin.okta.com, for instance. I also turn off auto fill for this reason.
I think the default matching behavior should be changed, and the handling of HTTP Basic Auth should be changed to conform to it.
I think the default matching behavior should be changed, and the handling of HTTP Basic Auth should be changed to conform to it.
[deleted]
I don't understand people excusing this. Subdomains can be controlled by completely different entities.
If you scroll down, it appears that Bitwarden sends BasicAuth passwords in the clear over HTTP. This is a huge security hole, far bigger than the subdomain one.
It’s certainly an issue, but sending it over basic auth isn’t one of them. If the passwords were submitted via a login form (POST request), you can also read it over the wire.
With HTTPS, you can read the request only in the context of the browser.
You can't MITM (via Wireshark and similar tools, or over the network), unless you have a root certificate and override the website's certificate with it (assuming the browser allows root certificates, and Firefox can be configured to not allow custom root certificates). So no, not the same thing at all.
And if you meant that in the context of HTTP-only, well, arguably password managers should warn before autocompleting unsecure forms, and browsers should warn before sending the request.
You can't MITM (via Wireshark and similar tools, or over the network), unless you have a root certificate and override the website's certificate with it (assuming the browser allows root certificates, and Firefox can be configured to not allow custom root certificates). So no, not the same thing at all.
And if you meant that in the context of HTTP-only, well, arguably password managers should warn before autocompleting unsecure forms, and browsers should warn before sending the request.
BasicAuth is a plain text header, there is no other way to send it. Are you meaning it should only allow Basic Auth over https and refuse to login over http?
[deleted]
Sounds like a bug with autocomplete disabled, but I don’t see this as a security issue.
What is the risk with using Bitwarden in this circumstance? That I trust one server of the company but not the other and therefore a bad actor now has my creds?
What is the risk with using Bitwarden in this circumstance? That I trust one server of the company but not the other and therefore a bad actor now has my creds?
Or you trust one user of a company but not another. Many services give each org a separate subdomain. If they support basic auth for whatever reason then just going to the other organisation will give them a hash of your credentials.
With basic auth you give something more than that. You give the ACTUAL credentials, because they are base64 encoded and not hashed. It is trivial to decode them and have the raw values.
To assume that a user trusts the subdomain because she trusts the domain, is something I find insane.
To assume that a user trusts the subdomain because she trusts the domain, is something I find insane.
You're right. I was thinking of digest auth which at least has nonces and hashing. Basic does not.
So is the TL;DR by default bitwarden sends basic auth (always, even if 'autofill' is off, because of limitations of the webextension API) to other subdomains (up to the public suffix), people don't like this because they use broken sites that aren't on the PSL list but are effectively public suffixes, and so bitwarden is changing the default to only send basic auth to strict hostname matches?
This seems like kind of a nothingburger security wise to me.
This seems like kind of a nothingburger security wise to me.
So, you think it is my fault when Bitwarden send my Password to a site without my consence?
I'm saying it's the website's fault for not being on the PSL. If they have different trust for different subdomains
and they're not on the PSL they're broken for other reasons (like cookies) anyway.
I really really hate these piecemeal twitter "articles". Is there really no other way to inform the world about stuff?
https://github.com/bitwarden/browser/issues/1124 was the original issue, as far as I can tell.
Thank you.
Can you please change the title ? Its very misleading.
Why is the title misleading? Bitwarden leaked my password for subdomain A to subdomain B and does this even if auto-fill is set to off. That is exactly what the title says.
In my case even plaintext, because subdomain B has no HTTPS.
In my case even plaintext, because subdomain B has no HTTPS.
I learned about this from gorhill who is very diligent about appling this in uMatrix, etc[3].
[1]https://publicsuffix.org/
[2]https://wiki.mozilla.org/Public_Suffix_List
[3]https://github.com/gorhill/uMatrix/issues/264