
Bitwarden leaks passwords to other subdomains - mritzmann
https://twitter.com/RitzmannMarkus/status/1307614248835731456
======
pavon
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)

~~~
tialaramex
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](https://github.com/sleevi/psl-
problems) and
[https://news.ycombinator.com/item?id=24441942](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.

~~~
captn3m0
Another relevant read is the ICANN's research on the same:
[https://research.google/pubs/pub43821/](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.

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

~~~
xerxesaa
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
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.

~~~
SturgeonsLaw
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.

------
johnbatch
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)

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

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

------
Timpy
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?

~~~
jeroenhd
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
Is this true? Are you implying bitwarden doesn't respect the PSL? It seems
like it does.

~~~
jeroenhd
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...](https://blog.cystack.net/subdomain-takeover-chapter-two-azure-
services/)

~~~
EE84M3i
I agree completely. However, you listed "Github pages" in your examples which
is very well known to be on the PSL.

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

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

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

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

~~~
gruez
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
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.

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

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

~~~
EE84M3i
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.

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

~~~
mritzmann
Maybe this:
[https://threadreaderapp.com/thread/1307614248835731456.html](https://threadreaderapp.com/thread/1307614248835731456.html)

~~~
baal80spam
Thank you.

------
IceWreck
Can you please change the title ? Its very misleading.

~~~
mritzmann
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.

