[SECURITY] Bitwarden browser extension leaks basic auth credentials

[h-town]

While checking the NGINX logs on a machine hosting a site with HTTP Basic Auth I noticed a username which should not have been there. It was my own login but it was associated with the TLD site on hosted on a different machine, and here I was working with a subdomain.

After looking into it further I saw the extension--which was configured with default URL matching of "Base Domain"--was automatically volunteering credentials for the TLD, and doing so despite the fact that "Enable Auto-fill On Page Load" was disabled.

The Chrome and Firefox extensions were tested here and both exhibited the same behavior.

Although easing of HTTP Basic Auth in this manner may be viewed as a feature by some, it might feasibly compromise login data if targeted by bad actors. I'm sure there are several paths to exploit this but I've outlined 2 below:

• User stores credentials for myhome.dynamicdns.tld and uses the default "Base Domain" configuration of BW browser extension. Nefarious Ned sets up badactor.dynamicdns.tld with a Basic Auth website, somehow coaxes User to visit, and BW attempts to login using credentials stored for myhome.dynamicdns.tld. User is not notified of this attempt and backs out of the login prompt thinking all is well.

• User stores credentials for gmail.com and has the profile configured for "Begins With" matching. Vile Victor sets up gmail.com.badactor.tld with a Basic Auth website and somehow coaxes User to visit. Same scenario as above plays out here.

At the very least please discontinue automatic submission of credentials via Basic Auth if "auto-fill" is disabled. Ideally, and given many users may not understand the implications of this scenario, you'd remove the functionality outright.

[paudley]

This is very useful functionality - please don't remove it. If needed, a config option for it maybe. I suspect most people expect their password manager to work in basic auth scenarios.

[h-town]

This is very useful functionality - please don't remove it. If needed, a config option for it maybe. I suspect most people expect their password manager to work in basic auth scenarios.

When properly deployed I don't disagree! In its current state I have zero doubt that credentials have been unintentionally submitted to the wrong parties before. Perhaps not for either of us but its definitely happened somewhere, and that's a problem. Has it been actively exploited? Who knows...

[paudley]

It's possibly worth a per-item checkbox to support Basic Auth. I only use this on a very small subset of sites. Might also be worthwhile to limit it to HTTPS urls.

…

On Sat, Jan 25, 2020, 6:35 PM h-town ***@***.***> wrote: This is very useful functionality - please don't remove it. If needed, a config option for it maybe. I suspect most people expect their password manager to work in basic auth scenarios. When properly deployed I don't disagree! In its current state I have zero doubt that credentials have been unintentionally submitted to the wrong parties before. Perhaps not for either of us but its definitely happened somewhere, and that's a problem. Has it been actively exploited? Who knows... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1124?email_source=notifications&email_token=AAEAZQ6HTF7O3EGZCTD3U4TQ7TZIPA5CNFSM4KLUI6R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5KKIY#issuecomment-578463011>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEAZQYGKXPE5JWUQW6AHELQ7TZIPANCNFSM4KLUI6RQ> .

[mritzmann]

My suggestion:

• Send the HTTP Authorization Header only if the URL including subdomain matches. For the automatic filling out of Basic Auth the default matching with "Base domain" should be overridden.
• If auto-fill is switched off, this should not work.

[rugk]

…or just do it like KeePassXC seems to do in it's recent versions: always open a popup asking whether to proceed.

[RobertMe]

This might also be solved by changing "base domain" and using the public suffix list for this: https://publicsuffix.org/

This so that the extension knows that foo.dyndns.provider and bar.dyndns.provider are different domains under the same public suffix (dyndns.provider) and that credentials thus shouldn't be shared. This as this list for example is also used by browsers to determine if two domains are the same site to apply the SameSite cookie policy (so preventing cookies set on foo.dyndns.provider from being send to bar.dyndns.provider).

[rodalpho]

No, the proper fix is to not send basic auth across subdomains at all. Don't match base domains, only full domains. Very simple. @mritzmann has it right.

Please do not restrict it to HTTPS only. I use basic auth in my LAN.

Also please don't open a popup. That's annoying.

[kspearrin]

If auto-fill is switched off, this should not work.

One problem here is that, due to limitations in the web extension APIs (see chrome.webRequest.onAuthRequired), filling credentials for HTTP Basic Auth prompts has to be non-interactive. I know of no other way to do it. Because of this, we do not respect the "auto-fill on page load" setting.

We could change the default match detection to Host on basic auth fills. That's not a bad idea.

[rugk]

So whatever, there should of course be the possibility to disable that feature altogether. So any arguments like "That's annoying." or so don't count, because you can disable it.

No, the proper fix is to not send basic auth across subdomains at all. Don't match base domains, only full domains. Very simple. @mritzmann has it right.

Yeah, that's for a start may be a good idea, unless some users depend on that feature – you know.
Though even if that is restricted, you may not always like to automatically send this thing so hmm…

[rugk]

credentials for HTTP Basic Auth prompts has to be non-interactive. I know of no other way to do it.

KeePassXC can do it, maybe look at their source https://github.com/keepassxreboot/keepassxc-browser/
I guess they may just cancel and re-request or do such tricks.

[rugk]

Wait… your statement is just not true.
I just had a look on the docs https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired and it tells you many methods, which one is:

Provide credentials asynchronously

So technically that seems possible.

[kspearrin]

KeePassXC can do it, maybe look at their source https://github.com/keepassxreboot/keepassxc-browser/
I guess they may just cancel and re-request or do such tricks.

This seems to be because they have a native desktop app running that can open interactive UIs during the web request flow. Bitwarden works independently, only with available web extension APIs.

[kspearrin]

Changing the default match detection for basic auth fills has been addressed in #1397

[ottacom]

I'm wondering if sounds reasonable from a UX perspective to disable the autofill and use the right click instead and one for all disable auto-login from the browser

[punkrokk]

Yea this should be OPT IN

[LunNova]

Having no way to disable this is unfortunate.
I have autofill off, credentials should never be automatically filled.
Is there still no way to turn this off?

Seeing collaborators appear to disregard this as a nonissue is very disappointing.

[rodalpho]

They didn't ignore it, Kyle (BW's owner) addressed that here:

#1124 (comment)

Due to a technical issue, respecting the aut-fill setting for basic auth is not possible in an addon. Changing it to only match on full domains addresses the issue at hand.

[h-town]

They didn't ignore it, Kyle (BW's owner) addressed that here:

It was marked as an "enhancement" and still hasn't been addressed after 9 months and 11 releases...

[kspearrin]

resolved with #1397 for next release.

[LunNova]

Due to a technical issue, respecting the aut-fill setting for basic auth is not possible in an addon.

It is possible - by not filling the password at all. Requiring me to manually copy/paste is better than autofilling that I never enabled.

Raised #1408