7 ms·

Bitwarden leaks passwords to other subdomains

107 points by mritzmann 6y ago

baal80spam 6y ago
I really really hate these piecemeal twitter "articles". Is there really no other way to inform the world about stuff?
- mritzmann 6y ago
  Maybe this: https://threadreaderapp.com/thread/1307614248835731456.html https://threadreaderapp.com/thread/1307614248835731456.html
  - baal80spam 6y ago
    Thank you.
- isignal 6y ago
  https://github.com/bitwarden/browser/issues/1124 https://github.com/bitwarden/browser/issues/1124 was the original issue, as far as I can tell.
philliphaydon 6y ago
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.
- mritzmann 6y ago
  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.
- xerxesaa 6y ago
  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?
  - philliphaydon 6y ago
    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.
    - shakna 6y ago
      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.
    - SturgeonsLaw 6y ago
      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.
  - manojlds 6y ago
    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.
- belorn 6y ago
  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?
  - jeroenhd 6y ago
    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.
  - geofft 6y ago
    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.
    - anilakar 6y ago
      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.
- jbverschoor 6y ago
  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.
- zeeZ 6y ago
  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.
  - geofft 6y ago
    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".
    - andrewnicolalde 6y ago
      > If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure". Why not?
      - geofft 6y ago
        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.
      - fomine3 6y ago
        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.
    - zeeZ 6y ago
      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.
- deleted 6y ago
  [deleted]
- tialaramex 6y ago
  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/ https://example.co.uk/ it will provide those credentials automatically, without prompting, to the completely different, unsecured site http://cat-jokes.example.co.uk/ 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/ 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.
  - philliphaydon 6y ago
    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.
    - tialaramex 6y ago
      The on path attacker isn't hosting the website (static or otherwise) on http://cat-jokes.example.co.uk/ 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/ 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/ 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/ 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.
deleted 6y ago
[deleted]
Someone1234 6y ago
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."
davidg109 6y ago
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?
- viraptor 6y ago
  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.
  - niksakl 6y ago
    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.
    - viraptor 6y ago
      You're right. I was thinking of digest auth which at least has nonces and hashing. Basic does not.
IceWreck 6y ago
Can you please change the title ? Its very misleading.
- mritzmann 6y ago
  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.
deleted 6y ago
[deleted]
Timpy 6y ago
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?
- nichos 6y ago
  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.
- jeroenhd 6y ago
  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.
  - EE84M3i 6y ago
    Is this true? Are you implying bitwarden doesn't respect the PSL? It seems like it does.
    - jeroenhd 6y ago
      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-azure-services/ https://blog.cystack.net/subdomain-takeover-chapter-two-azur...
pavon 6y ago
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.
- justsomedood 6y ago
  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?
- gruez 6y ago
  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.
  - bad_user 6y ago
    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.
pavon 6y ago
This is a good opportunity to inform folks about the Public Suffix List[1]. In short, there is no algorithmic way to know how far up a subdomain is controlled by a single entity. For example ".org", ".co.uk", and ".cloudfront.com" are all public suffixes where subdomains under them are controlled by different entities. Mozilla created[2] the public suffix list to document these regions of control. If you write any software that gives subdomains the same privilege as the base domain, you should (at a minimum) check this list and verify that the subdomain is not known to be controlled by a different party. If you share a domain across multiple entities, you should add your domain to the public suffix list. I don't know if bitwarden uses PSL or not. I learned about this from gorhill who is very diligent about appling this in uMatrix, etc[3]. [1]https://publicsuffix.org/ https://publicsuffix.org/ [2]https://wiki.mozilla.org/Public_Suffix_List https://wiki.mozilla.org/Public_Suffix_List [3]https://github.com/gorhill/uMatrix/issues/264 https://github.com/gorhill/uMatrix/issues/264
- tpetry 6y ago
  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.
  - paulryanrogers 6y ago
    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.
    - mekster 6y ago
      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.
    - FDSGSG 6y ago
      How does this have anything to do with ICANN selling out?
aaomidi 6y ago
I don't understand people excusing this. Subdomains can be controlled by completely different entities.
johnbatch 6y ago
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
Ancapistani 6y ago
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.
mekster 6y ago
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.
- mritzmann 6y ago
  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.
  - mekster 6y ago
    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.
addicted 6y ago
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?
- mritzmann 6y ago
  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.
EE84M3i 6y ago
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.
- mritzmann 6y ago
  So, you think it is my fault when Bitwarden send my Password to a site without my consence?
  - EE84M3i 6y ago
    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.

107 points by mritzmann 6y ago

baal80spam 6y ago

I really really hate these piecemeal twitter "articles". Is there really no other way to inform the world about stuff?

mritzmann 6y ago
Maybe this: https://threadreaderapp.com/thread/1307614248835731456.html https://threadreaderapp.com/thread/1307614248835731456.html
- baal80spam 6y ago
  Thank you.
isignal 6y ago
https://github.com/bitwarden/browser/issues/1124 https://github.com/bitwarden/browser/issues/1124 was the original issue, as far as I can tell.

philliphaydon 6y ago

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.

mritzmann 6y ago
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.
xerxesaa 6y ago
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?
- philliphaydon 6y ago
  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.
  - shakna 6y ago
    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.
  - SturgeonsLaw 6y ago
    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.
- manojlds 6y ago
  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.
belorn 6y ago
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?
- jeroenhd 6y ago
  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.
- geofft 6y ago
  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.
  - anilakar 6y ago
    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.
jbverschoor 6y ago
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.
zeeZ 6y ago
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.
- geofft 6y ago
  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".
  - andrewnicolalde 6y ago
    > If it doesn't work reliably and people end up copying/pasting passwords, that's not the "most secure". Why not?
    - geofft 6y ago
      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.
    - fomine3 6y ago
      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.
  - zeeZ 6y ago
    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.
deleted 6y ago
[deleted]
tialaramex 6y ago
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/ https://example.co.uk/ it will provide those credentials automatically, without prompting, to the completely different, unsecured site http://cat-jokes.example.co.uk/ 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/ 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.
- philliphaydon 6y ago
  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.
  - tialaramex 6y ago
    The on path attacker isn't hosting the website (static or otherwise) on http://cat-jokes.example.co.uk/ 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/ 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/ 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/ 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.

deleted 6y ago

[deleted]

Someone1234 6y ago

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."

davidg109 6y ago

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?

viraptor 6y ago
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.
- niksakl 6y ago
  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.
  - viraptor 6y ago
    You're right. I was thinking of digest auth which at least has nonces and hashing. Basic does not.

IceWreck 6y ago

Can you please change the title ? Its very misleading.

mritzmann 6y ago
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.

deleted 6y ago

[deleted]

Timpy 6y ago

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?

nichos 6y ago
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.
jeroenhd 6y ago
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.
- EE84M3i 6y ago
  Is this true? Are you implying bitwarden doesn't respect the PSL? It seems like it does.
  - jeroenhd 6y ago
    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-azure-services/ https://blog.cystack.net/subdomain-takeover-chapter-two-azur...

pavon 6y ago

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.

justsomedood 6y ago
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?
gruez 6y ago
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.
- bad_user 6y ago
  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.

pavon 6y ago

This is a good opportunity to inform folks about the Public Suffix List[1]. In short, there is no algorithmic way to know how far up a subdomain is controlled by a single entity. For example ".org", ".co.uk", and ".cloudfront.com" are all public suffixes where subdomains under them are controlled by different entities. Mozilla created[2] the public suffix list to document these regions of control. If you write any software that gives subdomains the same privilege as the base domain, you should (at a minimum) check this list and verify that the subdomain is not known to be controlled by a different party. If you share a domain across multiple entities, you should add your domain to the public suffix list. I don't know if bitwarden uses PSL or not. I learned about this from gorhill who is very diligent about appling this in uMatrix, etc[3]. [1]https://publicsuffix.org/ https://publicsuffix.org/ [2]https://wiki.mozilla.org/Public_Suffix_List https://wiki.mozilla.org/Public_Suffix_List [3]https://github.com/gorhill/uMatrix/issues/264 https://github.com/gorhill/uMatrix/issues/264

tpetry 6y ago
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.
- paulryanrogers 6y ago
  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.
  - mekster 6y ago
    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.
  - FDSGSG 6y ago
    How does this have anything to do with ICANN selling out?

aaomidi 6y ago

I don't understand people excusing this. Subdomains can be controlled by completely different entities.

johnbatch 6y ago

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

Ancapistani 6y ago

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.

mekster 6y ago

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.

mritzmann 6y ago
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.
- mekster 6y ago
  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.

addicted 6y ago

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?

mritzmann 6y ago
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.

EE84M3i 6y ago

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.

mritzmann 6y ago
So, you think it is my fault when Bitwarden send my Password to a site without my consence?
- EE84M3i 6y ago
  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.