Bitwarden leaks passwords to other subdomains
twitter.com
twitter.com
I learned about this from gorhill who is very diligent about appling this in uMatrix, etc[3].
ICANN is one of the internet's failure.
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.
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.
https://github.com/bitwarden/server/blob/0f1efdd18b879ccdf41...
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?
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.
Any popular service at this point wouldn't be allowing user content on their main domain.
The submission process is done via a pull request, described here:
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 now configured the domain matching correctly, but the default has burned me more often than I'd like.
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.
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.
Why not?
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.
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.
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.
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.
So Bitwarden’s behaviour is a protocol violation.
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."
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?
If they don't, I'd still say you're reasonably safe given that you're using unique passwords.
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.
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...
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 think the default matching behavior should be changed, and the handling of HTTP Basic Auth should be changed to conform to it.
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.
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?
To assume that a user trusts the subdomain because she trusts the domain, is something I find insane.
This seems like kind of a nothingburger security wise to me.
In my case even plaintext, because subdomain B has no HTTPS.