Abusing Okta's SWA authentication

This blog post covers the implications of using SWA as an authentication method in Okta, with a particular focus on what security teams need to consider in an account breach and subsequent incident response scenario. 

Spoiler alert: we’ll make the case that the true value of an SSO solution like Okta is in the use of SAML and OIDC authentication methods, not convenience features like SWA.

Introduction

To facilitate SSO logins to web applications, Okta allows the industry standard SAML and OIDC protocols for federated logins to be used with applications that support it. These represent the most secure and recommended options. However, Okta also offers a proprietary system called SWA to support apps that don’t support these protocols, or where they are otherwise unavailable due to licensing restrictions.     

While SWA is referred to as an SSO login mechanism, functionally it’s a password manager. SWA stores username and password combinations for individual applications on a per-user basis and makes use of a browser extension to automate the login process on behalf of the user. 

The screenshot below shows an example of an application being configured to use SWA as opposed to SAML, in this case Salesforce:

From this configuration screen it’s not obvious that there is a fundamental difference between some login methods like SWA and true federated identity methods like SAML 2.0. To better understand the difference and the risks of SWA, let’s look at it from an attacker’s perspective.

How are Okta accounts compromised?

While it’s common for Okta accounts to be protected using MFA, and sometimes device trust, there are still viable attack vectors. The two most prevalent attacks would be: 

• Endpoint compromise - In a traditional endpoint compromise scenario, an attacker will generally have full access to the user’s browser. This means they can hijack existing Okta sessions by stealing authentication tokens, which bypass all device trust and MFA protections. For persistent access, they can keylog credentials when the user next logs in and add MFA methods or enrol a new endpoint with device trust.

• Phishing attacks/MFA proxying - Traditional phishing attacks can be launched against Okta users to obtain credentials and/or authenticated sessions. Attacker-in-the-middle (AITM) attacks can be used to bypass common MFA mechanisms, and attacks against Okta users are typically carried out using tools such as evilginx, noVNC or cuddlephish. We’ve even seen groups using tooling specifically crafted to target Okta such as the notorious 0ktapus group/campaign.

What is Okta SWA?

Okta Secure Web Authentication (SWA) provides SSO-like functionality to web applications that don’t support federated protocols and is intended to be used only when SAML or OIDC federated logins cannot be used. 

It is SSO-like in the sense that:

• A user enters their single Okta password to login to Okta, 

• SWA then stores username/password combinations 

• SWA then makes use of a browser extension to automatically login to applications using the credentials. 

In that sense, it’s essentially a password manager. Like any password manager, it can be a big security improvement over a user manually managing their accounts or reusing the same password everywhere.

There’s a good reason that true SSO is considered more secure than password managers, and this comes down to the identity. An SSO uses a single identity that is federated to other apps, where a password manager just better manages many discrete identities. So, when an employee leaves an organization and they’re using an SSO, a single identity needs to be disabled, but disabling access to a password manager does nothing to disable the identities inside it.

In the case of SWA, the use of a browser extension and a long list of supported applications with custom login scripts already written is a key value add. This means users don’t need to copy/paste credentials like they might with some password managers. 

However, unlike typical password managers, there isn’t just one type of SWA, administrators can actually pick between one of five configuration options. This is shown in the screenshot below:

So, it’s possible to configure SWA like a traditional password manager scenario where the user sets their own username and password. However, as you can see above, you can set it up so that administrators can fully control the credentials, including the use of shared credentials used by multiple users.

SWA can also control the default configuration of the password reveal capability:

• When configured to allow users to set their own credentials, password reveal is enabled by default. 

• When administrators control the credentials, password reveal is disabled by default. 

Since Okta SWA performs logins automatically on behalf of the user, the user doesn’t technically need to be able to view or copy/paste the credentials. This makes it possible for Okta to support disabling password reveal. 

What are the security risks of using SWA?

While SWA may be a step up from users performing manual logins to a range of apps, it carries the same risk that any password manager solution has. If your account is compromised then all your usernames and passwords can be stolen in one go.

But how can that be if password reveal has been disabled

1. Bypassing password reveal restrictions

Even if users don’t directly interact with their passwords themselves (e.g. via copy/paste), their browser needs access otherwise it wouldn’t be possible to login to apps. 

The Okta browser extension uses the user’s active Okta login session to request credentials in the background, then automatically logs in to apps without the user ever directly seeing those credentials. So, while disabling password reveal may defeat a low-skill attacker or normal user scenarios, it’s essentially a client-side control, and isn’t going to stop a more determined attacker or technical user from getting at the credentials. This isn’t a bug, it’s a technical limitation of how a password manager works.

For example, let’s say a user has Salesforce configured as an app with SWA and clicks the app tile in the extension to login. The browser extension will use the active user session to make a request like the following (headers and irrelevant data removed for clarity):

GET /api/plugin/2/app/salesforce/0oa5ybnree2VPL6EA0x7/flow?plugin_version=6.20.0-73.101.0 HTTP/2


{
  "scripts": {
    "script": [
      {
        "action": [
          {
            "id": "username",
            "value": "lukejennings@bugcrowdninja.com",
            ...
          },
          {
                        "id": "password",
                       "value": "MySalesforcePassword1",
            ...
          },
          {
            "type": "click",



            "element": "css=input[id=\"Login\"]",
            ...
          }
        ],
        "name": "Login"
      }
    ]
  },
  "urls": {
    "match": [
      {
        "exact": false,
        "isRegex": false,
        "matchFrames": false,
        "url": "https://login.salesforce.com",
        "scriptName": "Login"
      }
    ]
  },
  "annotated": false,
  "hasEncryptedValues": false,
  "appName": "salesforce",
  "signOnModeType": "BROWSER_PLUGIN"
}

This response to the browser extension’s web request contains the username and password for Salesforce

This is the Salesforce-specific login script that allows the extension to automatically log the user in to Salesforce and includes their credentials. This request will include the credentials even if password reveal is disabled - the request above was captured using an intercepting proxy like Burp Suite.

2. Cross-account shared passwords

An additional risk with SWA is an operational one. Administrators can set passwords for users and also disable password reveal, which can encourage the use of shared passwords, since they don’t expect the users to see them. 

If administrators are auto-generating complex passwords for every single user account they create as a strong operational process, then there may be no issue. However, breach history would tell us that rarely do organizations have operational security practices as stringent as that.

An attacker compromising an Okta user account can not only extract valid credentials for all configured SWA apps for that user, but may uncover passwords that are valid for other user accounts configured by administrators, making this a likely vector for lateral movement.

3. Shared Okta passwords

One SWA option administrators can configure is to require the user to use their Okta password for the application (see earlier screenshot of configuration options). In this case, Okta lets the user set the password for the application, but it will confirm it matches the user’s Okta password and reject it otherwise.

This is a dangerous option, since it means the user’s Okta password is shared with other applications. So, if one of those applications is compromised, then their Okta password could be breached as well, which could allow both other applications and the user’s core Okta account to be compromised. It’s essentially enforcing password re-use, the exact opposite of what you want from an identity security perspective.

4. Persistent access to connected apps

Okta acts as an authentication gateway for access to other applications. Ideally, strong authentication policies will be in place such as strong password policies, MFA, account lockout and detection and response controls.

However, if even a temporary compromise of an Okta account is achieved (for example through an Okta session theft), an attacker extracting all credentials for SWA apps does not need to maintain access to Okta any further. Instead, they can maintain persistent access to all the downstream SWA apps by logging in manually, using the credentials they have extracted without using Okta. 

This greatly complicates incident response playbooks. Where an otherwise simple recovery action like disabling an Okta account, resetting the password and MFA methods, et cetera, would kick an attacker out of the Okta account - for a user using SWA the attacker will still have all the access to downstream SWA applications unless every single SWA app user account is recovered as well. This is where the value of a federated identity becomes clear.

Dumping SWA credentials

Since Okta SWA functions as a password manager, and it’s also possible to bypass password reveal restrictions, an attacker who has gained temporary access to an Okta session can automate the extraction of all credentials stored via SWA for that account.

Using the password reveal API

One method would be to automate the password reveal API call in the dashboard for every app configured. This is the simplest, direct way to get credentials but has the disadvantage that it will not return credentials that have had password reveal disabled. The following screenshots show an example of the API call that is made:

Using the browser extension API

The more effective way for an attacker to dump credentials, and bypass password reveal restrictions, is to emulate the API calls made by the browser extension to retrieve the login scripts for each SWA application. 

For an attacker to make these calls, a valid Okta session is needed. Specifically, the tokens that need to be extracted from the browser for these calls are:

• The access token in “okta-token-storage” in browser local storage

• The “idx” token in cookies

These can be seen below:

The following screenshot shows the use of a simple internal PoC we created to investigate logging detection opportunities. It gives a sense of the type of information that can be retrieved for a test Okta user account: 

So if SWA can be risky, is SAML and OIDC safe?

In general, much more so, but as is unfortunately so often the case in security, the answer is “it depends.” The threat profile for federated SSO like SAML and OIDC is very different, and they don’t suffer from the risks highlighted with SWA use given above. 

Any organization using Okta should strive to use SAML/OIDC for as many applications as possible - this is the true power of a federated identity solution.

However, it’s important to remember that not even SAML/OIDC isn't a silver bullet.

For example, it’s still possible for an attacker achieving a temporary compromise of an Okta account to click every single SAML/OIDC application to establish authenticated sessions with all of them. While some sessions may be short-lived, depending on the application, these sessions may stay alive for longer periods such as 30 days or for some apps even indefinitely. 

While it may be simple for incident responders to disable an Okta account temporarily, it’s certainly much more difficult to disable all connected SaaS accounts and/or kill active sessions for all of them. 

Additionally, while active sessions won’t generally allow an attacker long-term access to an application like stolen SWA credentials often will, many different SaaS applications support methods that can be used to effectively backdoor access to them - though this is a risk to both SWA and federated identities.

This is another big challenge for incident responders to deal with, as it can allow attacks to maintain persistence without requiring valid credentials or active sessions. In other words, there are many ways to turn that short term access into persistent access outside Okta. 

While the full details of these persistence attacks are outside the scope of this article, more details on some key attacks can be found in a resource we created called the SaaS attacks matrix. Some of the most common techniques that apply here are:

• SAT1004 - API keys

• SAT1022 - Link sharing

• SAT1017 - Ghost logins

• SAT1027 - OAuth tokens

• SAT1033 - Shadow workflows

Investigating and detecting an Okta account compromise

The good news is there are multiple Okta log events that can be used for either investigating a breach or providing some detection mechanisms via a SIEM. Three key log events are as follows:

• Show password event - indicates when a user has clicked the reveal password button

• Evaluation of sign-on policy - occurs when the browser extension requests credentials

• User single sign on to app - occurs when a full app login is performed

Using these events in a post-compromise situation could potentially significantly reduce the response actions required. If there is clear evidence that the attacker only accessed a limited number of applications, focus can be placed on disabling those accounts and removing potential backdoors, as opposed to having to perform containment procedures for every single application the user has access to.

Short time-window detection

While the events above are great for investigation, they are all expected events during normal use of Okta by a user. Perhaps the “show password” event may be rarer, but it would still not be completely unusual to see. 

This makes detection more difficult as defenders need to separate malicious logins from legitimate logins, a notoriously difficult task.

For proactive detection, one option would be to detect unusually large numbers of these events in a short time window for the same user account. This would be especially effective against automated tools. It would be much more unusual to see a legitimate user login to every app or reveal every password all in one go, or even all in one day. On the other hand, an attacker may seek to compromise all applications in a short time window.

Given below is an example of the flurry of logs generated by running our internal SWA password dumping tool shown earlier. You can see they are all generated in a very short time window:

The only difficulty here is picking sensible numbers for the minimum number of apps and maximum time window required in order to generate a detection event. This would likely need customizing to individual environments based on what number of applications are typical for a user to have access to.

For more general Okta detection rule options, consider checking out the Okta rules contained in the open-source Sigma rule repository on GitHub.

Guidance for incident response

If there is one key takeaway from this article, it’s that responding to an Okta account compromise isn’t as simple as disabling the user’s Okta account and/or resetting passwords and MFA factors.

Once an attacker has compromised an Okta account, it should be initially assumed that all connected application accounts are also compromised, whether they use SAML, OIDC or SWA. 

If SWA is used, incident responders should also explore whether those passwords are compromised and whether any other accounts that potentially share those passwords are compromised. 

We’re going to assume all applications/credentials were accessed for the following containment advice, as it’s likely that even moderately-skilled attackers would have tools to automate this. 

A full belt and braces containment exercise would involve the following activities:

• Disabling/resetting the Okta account

• Disabling/resetting every single connected application account

• Identifying any other accounts that may share compromised SWA passwords for investigation and disabling/resetting

• Investigating every connected application account for signs of backdooring through multiple persistence techniques

The last point on investigating potential backdoors is particularly important because of the following reasons:

• Even if every application user account is temporarily disabled while passwords are reset etc, re-enabling the account could re-activate the attacker’s access if they have made use of persistence techniques like API keys and ghost logins

• Even if all application user accounts are disabled, even permanently, techniques like link sharing can enable attackers to maintain access to data because link sharing decouples the access from being reliant on control of a user account.

Impact

We’ve covered a lot of ground here, so let’s take a quick step back to understand the key points of impact:

• Attackers can extract passwords for SWA apps, even if password reveal has been disabled - to be clear, this is not a bug, it’s just a technical limitation on how this style of password manager login has to work

• SWA passwords set by administrators should not be considered secret from the users as they can be accessed via the extension API

• Attackers gaining temporary control of an Okta user account can establish authenticated sessions with SAML/OIDC applications. 

• These sessions won’t automatically be revoked if the Okta user account is disabled/reset in response to compromise

• There are multiple common attack techniques to gain persistent access to SaaS applications.  

• An attacker can potentially gain permanent access to many connected Okta applications even if efforts are made to reset individual application accounts

Conclusion

While many of these attacks are not unique to Okta, it is one of the most widely used products because it supports many apps, but it supports these apps using methods that have very different risk profiles. 

From a security perspective (and whatever your chosen identity platform), our recommendation would be to use SAML (the strongest auth method) where possible. If that isn’t available, use OIDC. If neither is an option, use password managers (like SWA), which in practise leads to far less reused passwords. 

Unfortunately the state of modern cloud app landscape means that you will be paying a lot more to get many apps using federated SSO, and even then many will still not support this at any license tier, so the use of passwords is still going to be part of the solution.

As we have seen in this article, an attacker can use a compromised SSO session to perform a number of follow-up attacks. Whether using SWA or SAML/OIDC it’s possible to gain authenticated sessions on connected apps and also potentially backdoor access to them.

When using SWA, it’s additionally possible to extract SWA passwords even when password reveal is disabled and potentially gain access to passwords shared with other accounts. This requires additional actions as part of your breach recovery processes/play-books.

There are multiple log events that can be used by security teams to investigate and respond to Okta account compromises and potentially detect them too. Additionally, strong incident response procedures need to be in place for dealing with compromised Okta or any other SSO accounts that factor in the ability for an attacker to laterally move to all the connected applications. Therefore, plans need to include revoking their access to those as well and investigating them for signs of backdoor persistence techniques.