Authomize’s Security Research Lab has released a new report outlining misconfiguration risks for Okta users that can lead to the theft of cleartext Okta master passwords and compromise of all cleartext passwords post-exploitation with a “living off the land” technique utilizing the Okta SWA (password manager) functionality.
In this post, we lay out what we found, how the attack is carried out, and how to protect against exploitation.
Findings
The risky misconfiguration uncovered by the Authomize team allows an attacker to connect a malicious application to Okta using the Secure Web Authentication (SWA) technology, which can then steal the master password with no actions required by the user.
Background
In many cases, Okta allows organizations to connect their applications to their Identity Provider (IdP)/Single Sign-On (SSO) service via federation protocols like SAML, Web Services Federation (WS-Fed), or OpenID Connect (OIDC). In the past we have also written about the use of SCIM connectors that can be used for stealing cleartext downstream applications’ passwords.
But in other cases, organizations may have external applications that do not support federation, and choose instead to use SWA. In essence, SWA is an enterprise password manager functionality common in many SSO solutions under different names such as “Same Sign On”.
In the event that they choose this option to connect to their application, the admin can set how the user connects.
One choice is for Okta to login to the application in a similar way that one would if they were using a password manager like LastPass or 1Password, using an autofill feature where Okta inputs the credentials for that specific application.
Then there is another way wherein the user, via Okta auto filling the fields, uses their Okta master password to sign in to their applications.
This is a very risky configuration because it means that the user is exposing their Okta credentials to all of their applications. It goes against a core security principle of avoiding password reuse, and mitigating risk in case of an account getting compromised.
Conditions for Success
Once the app is open in the browser, in order to fill the password, Okta’s extension should be installed in the browser, and must be approved to open pages. This is what allows Okta to autofill fields for apps.
The attacker needs to have privileges (as low as an app admin) in Okta.
How the Attack Works
- Achieve minimal level of admin privileges in Okta, app admin is sufficient
- Create a malicious SWA application in Okta to redirect to your malicious target page
- Configure the application to automatically launch using the Okta credentials and auto-submit
- Assign the targeted users / groups to the application.
- Once the victim logs into Okta (since auto launch is configured) the malicious app will open in a new tab and a GET request will be sent with the victim credentials (the browser plugin must be installed for the attack to be successful)
Pro tip: Set the malicious target page to quickly close so that it will not be noticed by the user
See this video for how to create your own SWA application for Okta
Response from Okta
In the spirit of responsible disclosure, Authomize reached out to Okta for comment. In their response, they stated that:
Secure Web Authentication (SWA) is an optional feature for organizations that want all application access to require login to Okta, while also needing to provide access to web applications where Single Sign On (SSO) via OIDC or SAML isn’t available. Because of this, Okta proactively warns customers via HealthInsight when they are using SWA for an application that supports Single SignOn via OIDC or SAML.
Additionally, the attack vector being presented here requires access to an account with Application Admin permissions in Okta. Meaning, in this case, that the “master password” mentioned by Authomize is the user’s Okta password if they were under exploit from a compromised administrator. To mitigate this, we recommend customers create de-scoped roles using Custom Admin Roles.
Lastly, Okta believes the monitoring and oversight of actions performed by users with administrative roles is a cornerstone of any well-designed security program. Events in which an administrator creates a new application are logged in System Log, which can be streamed to security tools at no cost to an Okta org. As always, we recommend scoping your Application Administrator accounts in a highly privileged manner. More details can be found on that topic here – Standard administrator roles and permissions.
We appreciate Authomize giving us the opportunity to respond to this article.
Mitigations
As this risk is a post-exploitation misconfiguration technique and not a vulnerability, we do not expect that there will be any fixes for it for the foreseeable future coming from Okta.
Our recommendations are to:
- Reduce the number of admins, of all levels, to reduce the probability of one of them either being compromised or acting maliciously
- Scope app admins very carefully if they have access to SWA (or SCIM, per our previous advisories) features
- Monitor your Okta with Identity Threat Detection and Response (ITDR) tools to detect:
- Risky misconfigurations
- Over-privileged accounts
- Inactive admins
- Active exploitations
Conclusions and Analysis
In allowing users to log into downstream applications with their master password for Okta, the team there made a decision in favor of ease of use and flexibility over security.
This is a decision that software designers make each and every day, and most of the time, they are in the right.
Okta’s customers rely on it to enable them to manage their identities and access with relative ease and safety, as they should be. Workers want to spend more time connecting to their apps and getting work done, not less.
The Identity Provider offers a wide range of features to make it easy for their customers to connect to their apps like SCIM and SWA for those apps that do not support federated protocols. This is a good thing that Okta is dedicated to their customers’ productivity.
This smoothness can come with some security tradeoffs in their design decisions that customers should simply be aware of as users of SSO/Identity Provider services. And take steps to secure these tools like the business-critical infrastructure that they are.
As we’ve seen from the recent research from Wiz into vulnerabilities in Microsoft Azure AD that compromises in your IdP can lead to account takeover of your other apps.
It is up to us to monitor our identity and access management (IAM) tools to detect the misconfigurations, posture risks, and even active threats when they occur. In practice this means implementing 3rd-party monitoring tools that will uncover these issues and help organizations to ensure their identity security.
To learn more about this risky misconfiguration, Identity Threat Detection and Response, our research into the Okta and Azure AD security, and more, contact us.
