Just to make it very clear from the start: you should use a password manager. They are not always foolproof, and this blog post will try to discuss some of its flaws, but they are way better than not having one.

This blog post will not cover any technical vulnerability that someone has assigned a CVE. Instead, it is more of a design discussion and some food for thought. With that said, ‘real’ vulnerabilities have been found while writing this, and chances are someone might find some on their own while reading this.

Autofill, a requirement for most issues

A lot of password managers have an Autofill feature enabled by default, which is a requirement for most of the problems that follow. Some even have Autosubmit, meaning the password manager will even submit the form so the user never has to see it.

Some have it enabled by default, and others who likely do not have it as an option in Settings.

Subdomains

As a general rule, password managers do not seem to discriminate whether it is a subdomain or not. If it is going to autofill your password on facebook.com it will do so on www.facebook.com or bob.www.facebook.com as well.

This is convenient, but potentially leads to a few security issues.

User-generated content

There are websites out there where you can put user-generated content on a subdomain. One example is when user-uploaded files end up at cdn.domain.com. Another common example are blog platforms where each user has their own subdomain, such as bob.blogplatform.com. If anyone can register a blog and edit their HTML-theme, they could put up a form harvesting passwords intended for blogplatform.com/dashboard.

How password managers have protected against this varies greatly. Some disabled autofill for subdomains that never have been autofilled before, other use a blacklist of paths/domains that should not be autofilled (this approach obviously does not take into consideration every site), but multiple do not do anything to prevent it.

This attack vector becomes increasingly important when password managers grow in usage, especially if you are building a service that targets people within the tech industry. In most solutions it is possible to disable either subdomains or Autofill in general on a case-by-case basis. Something like this might be worth recommending if you believe a great part of your audience use this.

Subdomain takeover

It is very common for website owners to misconfigure their DNS-records and that can result in an attacker being able to host their own content on your subdomains. Given that password managers will autofill your password, it will also execute this on the attacker controlled page as well.

More information about this attack type can be found here.

Shameless plug, but we also offer a service called Domain Monitoring Service to detect and prevent such attacks.

XSS

Even if your users are not supposed to be able to modify the content of subdomains, the same effect would occur if you would have a XSS vulnerability on any subdomain. Is it reasonable that an XSS on bob.whatever.domain.com leaks the password of domain.com?

An interesting thing about this is how some password managers in their bug bounty programs or Responsible Disclosure Policy have set their own subdomains as out-of-scope, meaning they are not interested in vulnerabilities being reported there. If the password manager provides a web-ui, the user could save their master-password in the password manager, and a XSS on their subdomain would then be able to leak it.

Their own interpretation of origin

Given that password managers do accept subdomains, it is clear that they do not follow the strict origin check as a web browser would do. Many password managers do not use the browser’s built-in APIs for this but instead write their own checks as well. This opens up for a security issue when the browser and the password manager have not reached consensus regarding origin.

For proof of this being an issue we do not have to go further than our own blog.

• How I made Lastpass give me all your passwords
• Scratching the surface of host headers in Safari

Trailing period

Even when it is not as obviously broken as in those blog posts, there are additional minor differences that can be discussed. One of those being the trailing period, google.com and google.com. is treated as different origin by web browsers but the same for a few password managers. As we have seen before, it can be problematic when variation without the dot but not the one with the dot  has been claimed at third-party vendors. Talking with smaller vendors, I have also experienced this not being taken seriously, given that the browser actually sees it as different origins (meaning cookies are not shared etc).

Public suffix

Given that you want to share passwords regardless of subdomains, you somehow need to decide what is a subdomain. You must somehow understand that a.example.com and b.example.com can share passwords, but not a.co.uk and b.co.uk. In browsers this is done by a list called the Public Suffix List. However, this same list is not implemented by all password managers.

That means that in some cases, you can look in the list if you want an example, anyone using the same public register would also share these password. Security aside this seems like an inconvenient bug, so a bit surprising it has not been fixed.

Regex-checks

Bitwarden is one of the password managers to offer the ability to write your own regexes to ensure it matches what you want. There does not seem to be any warnings in the actual settings, but the risks of this feature are made clear in the documentation.

The first hit I got when searching for this online was this Reddit-thread on URI Regex Matching Help. If you look at the regex someone suggested, or the initial one provided by the one starting the thread, it is obvious that it would also match https://bob.com/.google.com breaking the whole check. It is easy to imagine such mistake being very common, as we have seen similar issues with regex in other scenarios.

MITM

Man in the middle attacks are quite interesting in this context. More and more websites use HTTPS, including the ones that you visit the next time you connect to a malicious WiFi-network at the local coffee shop. So how do password managers affect all this?

The first interesting thing to note is if the password manager autofills your password, it is enough to connect for just a few seconds. Even if you plan to actually browse around the internet with a VPN, in public places you often need to first connect without one to go to some kind of portal and then turn on the VPN. This would be enough time for an attacker to redirect your browser to the interesting website, let the password manager do its job and then steal your login details.

Secure flag

Setting the secure-flag to cookies does not really do much if the victim is using a password manager. Why would we want to steal the session cookie if we could directly steal the password?

HSTS

HSTS is what normally protects against such attack. However, considering how most password managers treat subdomains, we quickly realize that for HSTS to have the desired effect we must also use the includeSubdomains-flag in the HSTS-policy. If that is not set, a malicious part can redirect you to thissubdomaindoesnotexist.example.com and host a website there which steals your password.

Equivalent domain

To make it worse, several of the popular password managers maintain something called Equivalent Domain list or similar.

If you save a password for facebook.com you want it to be available for messenger.com as well without having to make another entry for it. These password managers therefore provide a list (often found deep down in settings) on domains that are considered to be equal. Lacking HSTS on your equal domain is as bad as lacking it on your real one here. An XSS on your equivalent domain could also steal passwords from the main website.

Far from a surprise, these lists are not always maintained and the ones on it probably do not even know about it.

Bug bounty and security audit

We often write about bug bounties. The password managers that we have found security issues and blogged about (and those not blogged about) happened because they have bug bounty programs in place. Logically, those password managers without bug bounty programs have just as many flaws, but they are not getting reported in the same extent.

I do not have any data to back that up, but personally it is something I take into consideration when picking a password manager. There are other public reports if you want to look on what others have found: https://hackerone.com/reports/435618

I am not saying a bug bounty program would be a guarantee but it would be handled very well for that matter, stories like those are not unique either.

 

I was invited to a #bugbounty program of a password manager, offering $3000 for critical bugs. Found that a malicious website could use JavaScript to quietly steal visitors’ passwords belonging to any website, no other interaction. Assessment: not that serious, $500. #excited pic.twitter.com/Td5NFuHtDK

— Klikki Oy (@klikkioy) 3 april 2018

 

 

Similar reasoning goes for password managers that have not had a security audit done. For some interesting discussion around this, I would recommend the Git-issue created before Bitwarden conducted theirs: https://github.com/bitwarden/server/issues/27

The actual report from the security audit a few months ago is also very interesting to read: https://cure53.de/pentest-report_bitwarden.pdf

(If this blog post gave you any idea you want to try out, here are a few of the password manager’s public bug bounty programs which will pay you for reporting those issues: Dashlane 1password Lastpass Kaspersky F-secure Keepass)

Concrete actions

As a user

• Disable autofill. In a enterprise setting, this can often be forcefully disabled for everyone
• Choose a password manager with care. Do your research as there are a lot of ones out there that does not bring confidence.

As a website owner

• Do not limit password length
• Do not disallow certain characters, this really messes with the auto generation of passwords
• Use HSTS with preload, and if possible include subdomains
• Monitor your subdomains for subdomain takeovers
• If you must allow user-generated content as HTML, host it on a sandboxed domain

As a password manager developer

• Read the blog post once again

Misc

• I did not feel like covering the recent debate about memory based attacks on password managers would contribute much and as such left it out. 
• One option to get rid of most issues explained here would be to use a standalone password manager instead of one integrated with the web browser. However, in my opinion the benefit of the password manager decreasing the risk of phishing by verifying the origin is greater than security risk it may pose. Do your threat modelling and act accordingly.

---

Author:
Linus Särud (@_zulln)
Security Researcher