Phishing Your Password Manager
UPDATE: The founder of 1Password responded to this blog after it was posted and explained that the majority of password managers out there leverage Mozilla’s Public Suffix List (PSL) to determine how the domain is to be treated. He looked and saw that Auth0 was not on the list for whatever reason, so it seems likely some of these password managers do actually take subdomains into consideration, as long as they’re on the PSL. It seems to me an attacker setting up a phishing campaign would want to check the PSL first to determine if this type of attack would work first. My advice remains the same, however, that no password manager should auto-complete fields by default and if a subdomain does not match where the credentials were saved for, it should not be trusted by default.
The Discovery
I believe there’s a flaw in the way most password managers today recognize unique “sites”, which introduces (what I think is) a new attack vector. All password managers should fix this. Hear me out. The debate about the security of password managers has long been settled. If you don’t already use one, you really should consider it. There, thanks for coming!
I noticed something interesting the other day when I was logging into a Single Sign-on (SSO) authentication service. If you’ve read my other blogs you’ll know I use unique usernames as well as passwords on each site I have a user account on. In this case I was logging into my employer’s threat hunting and response portal, Scope, which uses Auth0. I noticed my password manager, Blur, auto-completed the username and password input fields with values as a good password manager should. Although in this case, these credentials were for another site I previously used with Auth0, which was apparent to me because of the different usernames. My employer, Pondurance, uses Auth0’s Custom Domains feature so the login page is actually hosted by Auth0. I think you probably know where this is going. I found it odd, and insecure, that Blur (formerly known as DoNotTrack) wouldn’t recognize the subdomain in addition to the domain in order to identify the unique sites and retrieve credentials for them. It also got me thinking, what are the attack scenarios here and what other password managers are like this, if any?
The Research
Naturally I signed up for and downloaded a handful of the most common password managers I’m familiar with, in addition to the major players in the browser wars. Another thing you’ll pick up from my previous blogs is that I’m a big fan of phishing and often get to participate in social engineering engagements pretty regularly. I immediately thought of cloning a landing page to see if I could get Blur to auto-complete credentials into those fields and capture them when posted. I also wanted to know more about Auth0’s custom domains, specifically, because I figured if I could customize the code myself I could also add some malicious JavaScript and perform Formjacking. Typically when phishing and cloning fake portals, the attacker doesn’t have the advantage of having the victim’s password manager send them the credentials! It can also be a red flag if they’re used to this, but the fake domain doesn’t prompt them, since it’s not the same domain. The recipient may be wondering why they have to enter their credentials in manually and the game may be up.
I decided to stick with Auth0 (although just about any should work) for my research and figured cloning my company’s Scope portal was just as good as any place to start. I signed up for Auth0 with a free account (22 days seems like an odd trial period) which gave me temporary perks a free account wouldn’t normally have, namely the custom domain feature. I also learned that custom domains are available with any paid subscription package and their cheapest offering is $23 a month, not too shabby for a phishing domain. It’s also free to chose a subdomain and edit the contents of the page, so I chose the very inconspicuous name of “phakephish”.
I set up my fake domain to submit credentials to my PhishAPI so I could receive them in Slack. I tested this out and confirmed I could capture credentials, which I fully expected to work. When I visited my fake portal, my real Scope credentials were auto-completed as I had hoped. In this scenario the victim would see the auto-complete or choose the credentials manually from their password manager (if auto-complete was disabled) and it would appear to be legitimate. Awesome!
However, I really wanted to go the Formjacking route, leveraging my JavaScript keylogger I wrote a few years back, so that I could receive credentials without any user interaction being required, aside from visiting the site in their browser. That would be something, right!? Right..?
I inspected the HTML form elements and saw that it would be pretty trivial to read the values out of the input fields, so I customized the landing page further (while not caring about the look any longer) and added this new functionality.
I set up the JavaScript to call my Burp Collaborator service for demonstration purposes, and set it to post the current values every second (1000ms). I realized it takes some password managers time to make it look like it’s typing in the values. This worked really well and I played around with typing and watching the responses come in like a keylogger for the email and password fields. It also sent my credentials automatically as expected since Blur volunteered my information. Thanks.. Blur.
Okay, this is bad. I just received creds for a different Auth0 site by just visiting it with the “wrong” password manager, or so I though. This is also surprisingly easy and quick to set up, thanks to how helpful and intuitive Auth0 is.
Bad Blur! Time to see if any other password managers were vulnerable as well. Surely Chrome and Firefox’s built in password managers do a better job of at least checking the subdomain for uniqueness! No, no they do not. Edge does, of all things. Spoiler alert!
Here’s me checking each one manually:
Surprisingly, Edge and LastPass did not recognize the domain as the same, seemingly doing the “right thing” and treating the subdomain as unique. This prevented me from carrying out my attack.
Lastly, I noticed some of the password managers provide the option to “auto login” which terrified me, and rightfully so. That seemed to work just fine with this attack, which means if I wasn’t FormJacking and just gathering credentials posted by the form, I would be able to receive those again without any user input. Here’s a matrix I created because I like cool charts:
Conclusion
As you can see from the graphic above, most password managers I checked are vulnerable to phishing by default. I’ve never phished a password manager before.. I don’t see a good reason why any of these should not take the subdomain into account, especially now that there are so many SSO options and authentication/authorization providers out there today. Although I only checked Auth0, this is also likely true with Okta, MS365, and any other places where you can have either a custom domain or a vanity landing page. From an AppSec perspective, we’re always telling devs to add the “autocomplete=off” attribute to sensitive input fields and this is surely worse. As an attacker I have the extra privilege of not having to buy a domain and host it somewhere. If anything comes out of this blog, I’d love to see password manager vendors make this change to help protect their users. Otherwise I have an Okta phishing engagement coming up soon I’d love to use this on. :)
Update
I also realized I can add HTML forms to the body of email messages and phish directly from from the email! I can do this in Chrome with a little Dev Tool manipulation (see below image). What’s really interesting is that here again, the domain is recognized as Google.com and my browsers and password managers want to willingly give up my EMAIL CREDENTIALS! This should work with Microsoft 365 and most other web-based email providers as well!
Thanks for staying! Oh, and I have to plug my Children’s books of course @ misformalware.com. Please pre-order if interested!
