Can my admins steal my cloud password manager secrets?

Admin accounts - the keys to the kingdom?

Traditionally, admin accounts have tended to be pretty all-powerful in terms of the infrastructure they control access to, a kind of master key. An admin of a file server? Can see any files on that server they like. A windows domain admin? Can access any system connected to that domain, access password equivalents for every domain account, and even deploy code remotely to all connected systems. Necessary and practical for admins, but a nightmare for blue teamers.

In the realm of cloud identities and SaaS apps, the situation has changed a bit. An account with administrative access for a given SaaS app is limited by what that particular app does and what administrative features it offers. This means the traditional “all-powerful” admin account isn’t always really all-powerful in practice. 

For example, an administrator of a file storage SaaS app may not automatically have rights to view all personally stored files for an individual user. Similarly, an administrator of a corporate password manager app does not automatically have the ability to view the secrets their users are storing in the application. This is desirable as passwords, and thus password managers, are a key part of identity infrastructure - even admins shouldn’t be able to easily access passwords and secrets stored within.

This is a good thing as it limits the reach of a compromised account and creates additional steps for a user with malicious intent. But like anything password managers can be targeted, bypassed, and misused, particularly in the context of Cloud identities and SaaS.

How do password managers work?

Well, it depends! 

Typical password manager functionality involves a “password vault” being encrypted with a password/secret that only the user knows - commonly known as a “master password”. This vault might just be a file that can be stored anywhere, such as locally on a user’s laptop or remotely on a managed file server.  

Therefore, an admin of a file server might be able to see the password vaults, but won’t be able to recover the passwords inside without knowing the correct master password to decrypt them. However, a domain or desktop admin might be able to deploy malicious code to a user’s endpoint to keylog, or otherwise steal, their master password. This is more difficult than merely accessing an encrypted vault but is a viable attack technique.

For cloud-based password managers this concept is simply ported to the world of SaaS. Here, the vault is stored securely on the vendor’s servers and access is via a web app or browser extension, rather than a desktop application opening a stored file. Often the password a user uses to login to the app doubles up as their master password, but in other solutions they might be two separate concepts. 

So how does this change the threat? Well, it’s possible that domain/desktop admins might still be able to go the malicious code deployment route to steal master passwords. However, admins of the password manager app (or any app) should not typically be able to just access any passwords they like.

Why even use password managers when you could use SSO?

Strong SSO mechanisms such as SAML are good security controls and should be encouraged. But there are many reasons why they can’t always be used. Not all apps support them, some apps require much more expensive license tiers in order to enable SSO support, many apps will be self-acquired by users rather than centralized IT, some secrets are recovery codes that need to be stored somewhere… the list goes on!

Put simply, you will never have all your apps on SSO and there are many other use cases for secure storage of secrets, so it’s best to provide a secure password management solution to your users rather than having them use shared passwords everywhere, use easily guessed passwords, or generally record them in less secure ways. 

But what happens when a large organization adopts a SaaS-based password manager solution? As a key app, it definitely needs the highest levels of security protection, right? So the password manager itself should definitely be on SSO with a robust form of MFA applied. Users shouldn't be able to use any old single-factor password to access a store for important secrets that are tied to so many other sensitive corporate assets.

This leads us on to our next question - how does SSO impact the relationship between accessibility of stored secrets and the use of decryption keys only known to the users?

Controlling password manager access via SSO

Many solutions will allow administrators to control login to accounts via an SSO mechanism instead of the vendor’s own authentication mechanism. In this case, we’ll be using Dashlane as an example. This is not a specific vulnerability in Dashlane, we’re just creatively (ab-)using a legitimate feature. We haven’t picked on Dashlane for any particular reason and there are many more examples of this.

In this case, we’ve configured Dashlane SSO to use their confidential SSO mechanism that applies SAML as the SSO mechanism. We've then configured the supplied SAML details as an app in Okta and saved the resulting IdP metadata link in Dashlane. This allows Okta to now act as an identity provider for Dashlane.

This means that for verified domains that have been configured to use SSO in Dashlane, the Dashlane login process will now automatically relay to the given Okta tenant to handle authentication via SAML.

It’s worth noting that Dashlane only allows this for verified domains. An administrator setting this up the first time or later changing the SSO settings will need control of the DNS domain(s) their users use, or at least have the ability to request other DNS admins verify the domain on their behalf.

That’s it - it’s really that simple. Now your Dashlane instance benefits from whatever strong authentication policies you have in place on your centralized IdP, in this case Okta. That may include strong password policies, multi-factor authentication, auditing of all logon events for your account, etc. What could be bad about that?

Password stealing and lateral movement

As we covered earlier, the original security contract of traditional password managers was that only the creating user should have access via a master password - admin accounts should have no access beyond seeing the encrypted vault files. 

However, the SaaS-ification of password managers over time and integration with other parts of the identity management stack means that they are prone to the same weaknesses as many other apps - only in this case the prize is the secrets and passwords used to gain access to a huge number of other systems that those admins wouldn’t otherwise have direct access to. For an attacker looking to move laterally, this is a goldmine! 

We’ll now consider how two different types of admin accounts can use this functionality to gain access to password secrets for lateral movement elsewhere, in the event of a compromised admin account or insider threat.

SaaS admin - modifying SSO settings

Continuing the Dashlane scenario, an administrator of the app can simply modify the SSO settings in order to point to a different IdP that they control. This could be a different Okta tenant they have set up themselves, or it could be an entirely different IdP. 

In this case, we can simply change the IdP metadata to point to a different SAML endpoint. Pointing to a different Okta tenant means we can now login to Dashlane using a different identity provider as before. 

The implication here is that the malicious/compromised admin account can simply configure their own malicious IdP in a way that they can authenticate with any account. They can then use this to login to Dashlane as any user they like. The only caveat in the case of Dashlane is that Dashlane admin accounts cannot use SSO and so the malicious admin cannot access other admin accounts' secrets so easily. 

Our malicious admin can then simply login to access their account of choice and view the secrets as they please. They can do this manually, or they can even use the export functionality to export the entire password vault into a CSV file. The latter is disabled by default in Dashlane, but we’re an admin, right? So we can just enable the security policy to allow it!

Fortunately, a simple implementation of this attack will break logins by other users, as all users will be directed to the new malicious IdP. This means the attack is more likely to be quickly detected once users begin questioning why they cannot login to their Dashlane account. 

Unfortunately, attackers can take steps to avoid this by building a more sophisticated malicious IdP that accepts any password or performs some other clever redirect. This means that legitimate users can still successfully access their Dashlane accounts while the admin simultaneously hijacks their target accounts. 

One method is to use the Oktajacking technique discussed in this article to accept any credentials the user enters, while also keylogging them for further use. This enables the attacker to login as any user they like while also ensuring the real user can still login, whatever credentials they enter. This would allow the attack to go unnoticed for longer, giving the attacker the time and space to achieve their objectives without being hounded by incident responders (and in some cases persisting indefinitely).

Okta admin - external IdPs and routing rules

OK, obviously an admin account for Okta (or any type of IdP) is a very powerful tool for an attacker and there are plenty of malicious actions they could take. In this case we’ll consider how they could use it to gain access to Dashlane as any user, assuming Okta was being used as a SAML IdP as in the example above.

The simplest path here would be to use an external IdP, along with a routing rule, to allow the admin to login to Okta using a separate IdP they control, whilst continuing to allow the user to authenticate. This way, the user themselves would have no idea anything else had changed, but the attacker could easily impersonate any user they choose.

Adam Chester’s iconic post on Okta for red teamers covers the user of a malicious SAML provider for authenticating as any user and he even includes a simple python based SAML IdP that allows for this.

If we combine this with Okta routing rules, then we can create a targeted backdoor that allows the attacker to utilize their Okta admin account to login as any user they like in order to access their Dashlane password vault, while being completely transparent to the real users. We can do this by ensuring the external identity provider is only used when logins are performed from the admin’s IP address and/or specific devices.

So what?

Shock, horror, admin accounts can be used to do bad things! Of course that’s the case, but it is important that as security practitioners we fully understand the implications of security decisions we make and have plans in place for if/when incidents arise.

We’ve known for many years that an attacker compromising a Windows desktop or Linux server can potentially steal passwords and other secrets from that system. We’ve also known that if an attacker compromises an entire Windows domain, then we should consider every single user’s password compromised. 

While incident responders would much prefer to contain an incident before a complete domain compromise is achieved, we at least know we have to have a plan in place for how to deal with all domain passwords having been compromised, plus golden tickets, silver tickets and all other manner of backdoors.  

Of course, password managers are important to protect generally, but are we considering the true consequences and impact of either a malicious admin or a compromised admin account potentially allowing all password secrets to be stolen? Do we have a plan in place for how to recover from that like we would in the event of a windows domain compromise? These are the questions we need to be asking ourselves.

Impact summary

We’ve covered a lot of ground so let’s quickly take a step back and consider the key points of impact here:

• SaaS-based password managers often allow SSO mechanisms with MFA which can provide stronger authentication, instead of the passwords being stored in a file encrypted with a single factor master password, which changes the risk profile

• That said, compromised admin accounts for either password manager apps, or their SSO IdPs, can be abused by attackers to steal passwords at scale by hijacking the SSO process

• This technique could become the windows domain hash dumping equivalent in the new cloud identity and SaaS-based world

Conclusion

Password managers have quickly become an increasingly important part of identity security infrastructure. Passwords, and more generally secrets, are not going anywhere. So it makes sense for security-conscious organizations to provide their employees with a good password management solution.

Consequently, this means they will increasingly become a crown jewels target within modern cloud and SaaS-based organizations going forwards, much like windows domain controllers have often been the crown jewels in the past.

There are many methods by which different types of compromised admin accounts can be used to gain access to password manager secrets at scale by abusing SSO mechanisms and so security practitioners need to be aware of these attacks and plan for recovery actions in the event of a major incident. 

The defensive plans we’ve historically relied upon weren't designed for these new attacker methods, which effectively creates a blind spot. The attacker's goal hasn’t changed, but the environment (and how it can be targeted) has evolved - which means defenders need to adapt.