Okta PassBleed Risks – A Technical Overview

What is PassBleed?

In July 2022, Authomize published a report detailing several risks in Okta, which were named “PassBleed.” The highlighted risks are related to password stealing and user impersonation. Okta is one of the leading identity and access management (IAM) service providers, used by some of the world’s largest and best-known organizations. Those organizations depend on Okta to provide secure access to their applications and services.

Authomize outlined four risks present in Okta that could allow a malicious actor to compromise accounts:

• Export cleartext passwords via a SCIM (System for Cross-domain Identity Management) application
• Intercept sensitive data over unencrypted channels
• Compromise an admin account in a hub or other downstream spoke from a spoke account
• Change an account name to spoof another user and/or hide malicious actions

Threat Hunting and Detection

Okta customers can perform threat hunting for indicators of these techniques if they are exporting their Okta logs to a SIEM. We’ll outline the specific events to search for in the following sections. AppOmni customers will receive an alert in their “Threat Detection” dashboard if any one of these rules trigger an alert in their environment.

Detecting the Export of Cleartext Passwords

In this attack scenario, a malicious actor requires two items as a prerequisite:

1. A SCIM server they control
2. An Okta account with permissions to add or update a SCIM app

If the above two conditions are met, the malicious actor could add a new SCIM app and enable the “Sync Okta Password” setting. Once the new SCIM app is configured, the actor would then add the SCIM app to either an existing group of users, or a newly created group. This will enable the target group of users to now sync with the malicious SCIM server. Syncing of user accounts will include account metadata and cleartext passwords.

AppOmni’s Threat Detection rule, “Cleartext Passwords Exported with SCIM,” specifically looks for the following sequence of steps.

1. User adds a SCIM app within Okta.

• event_type == application.lifecycle.update
• outcome.result == SUCCESS
• debug_context.debugData.url contains “/admin/app/scim”
• debug_context.debugData.url contains “/instance/_new_”

The following audit log illustrates an example of this event.

2. User enables password syncing with “Sync Okta Password” selected.

• event_type == application.lifecycle.update
• outcome.result == SUCCESS
• outcome.reason contains “Pushing user passwords”
•  

The following audit log illustrates an example of this event.

3. One or more users are synced with a SCIM server.

• event_type == application.provision.user.sync

The following audit log illustrates an example of this event.

Each of the events in this sequence rule is correlated on the app name. This value is found in the field target.displayName where type == AppInstance.

Detecting Interception of Cleartext Passwords Over Unencrypted Channels

If an Okta SCIM application was created following the above sequence of steps, and the SCIM server protocol is HTTP, another risk applies. Using an unencrypted protocol means that any adversary with the ability to sniff traffic to your SCIM server can intercept user data, including cleartext passwords.

Unfortunately, Okta does not log the SCIM server URL in an event, so detecting this risk by threat hunting is not currently possible. See #3 under the Recommended Mitigations section below for steps to manually check the URL from the Okta tenant.

Detecting Hub or Downstream Spoke Admin Compromises

In this attack scenario, there are a couple of prerequisites. This is a common implementation for maintaining separate security boundaries for acquired companies, contractors, or different company organizations:

1. An Okta “spoke” organization must exist under a “hub” organization.
2. Out-of-the-box name duplication must be allowed. It’s possible by default unless a mitigation is implemented. See #2 under Recommended Mitigations.

A malicious actor would then need both of the following:

1. A user account in the “spoke” organization with permissions to create new users. This does not necessarily have to be a super admin account.
2. To know the email account of an admin user of their “hub” organization.

The malicious actor would then create a new user account (or update an existing one) using the same email address as an admin in the “hub” organization. When the new account is synced to the hub, it inherits the same permissions as the legitimate admin it’s impersonating. Now the malicious actor can just login to the hub organization using the credentials of their “fake” account. They’ve essentially elevated their permissions to match the target admin.

Threat hunting for this attack requires looking at events from both the Okta spoke organization and the hub organization. It isn’t possible to definitively identify this scenario with only events from one tenant because we need to correlate the user sync on the spoke to the user update on the hub.

AppOmni’s Threat Detection rule, “Possible Hub Compromise By User In Spoke Org,” specifically looks for this sequence of steps:

1. In a spoke organization, when a user is added to a group that syncs to a hub organization OR a user who is already a member is updated, that user will be immediately pushed to the hub.

• event_type == application.provision.user.push_profile
• outcome.result == SUCCESS
• debug_context.debugData.appname == “okta_org2org”

The following audit log illustrates an example of this event.

2. Now in the hub organization, we should see an event for the same user being updated. This event should be immediately following the previous events, usually no more than one second apart.

• event_type == user.account.update_profile
• outcome.result == SUCCESS

The following audit log illustrates an example of this event.

Each of the events in this sequence rule is correlated on the field target.alternateId where type == User, which contains the value of the target user’s email address.

From these two events, we don’t yet know if the user is an admin, and that context isn’t included in either event. This could just be normal activity where a legitimate user is being added or updated. Determine if the target user has an admin role, particularly “Super Admin.” If so, then this activity is worth escalating for further investigation.

AppOmni implements Unified Identity across all events to provide additional context as to the identity and roles of a given user. For this rule, an alert is triggered only if the target user has a super admin role. AppOmni’s approach to Unified Identity is explained further in the next section.

Detecting Mutable Identity Log Spoofing

By default, any Okta user can change their first and last name. This is not uncommon in most SaaS apps. So why is this an issue here? Because Okta records the user’s full name at the time of each action. That name is displayed in multiple places in the dashboard (such as Reports > System Log) and in generated audit logs. Therefore a user can change their name, perform a malicious action, and then change their name back. If an admin is reviewing activity based on displayed names only (as opposed to user ID) then they may be misled by a user’s true identity.

When threat hunting for activity where a user may have spoofed their identity, it’s critical to pivot on their ID instead of name. In Okta events, this is going to be actor.id. Determine the sequence of actions performed by the user’s ID and then check whether their name was changed before, during, or after any suspicious actions.

AppOmni’s Unified Identity allows our customers to keep track of a user’s identity, even across different SaaS platforms when their name may vary. For example, let’s say Mary Jones has the username mjones in one platform and mary.jones in another. AppOmni will analyze the metadata for these accounts to determine they are owned by the same person and can then correlate actions from both usernames. In this use case with Okta, AppOmni will know the identity of a user even when their displayed name is changed.

We make the assumption that it is unlikely that a user will legitimately change both their first and last name. We use that as a basis for alerting if a user may be attempting to mask their activity or impersonate another user. The Threat Detection rule “User Changed Full Name” looks for the following items in an Okta event.

• event_type == user.account.update_profile
• outcome.result == SUCCESS
• debug_context.debugData.changedAttributes contains “firstName”
• debug_context.debugData.changedAttributes contains “lastName”

The following audit log illustrates an example of this event. The id and alternateId fields are immutable. But notice the new value of displayName in both the actor and target fieldsets.

Recommended Mitigations

Authomize confirmed they shared their findings with Okta, but Okta has stated that they don’t classify these risks as vulnerabilities. Based on that information, it’s unlikely these risks will be fully mitigated by Okta. So what actions can you take to better secure your Okta organization?

1. Ensure you don’t have unauthorized or unnecessary Okta apps installed in your Okta organization. These can be viewed by any user with at least “Application Administrator” privileges on the Applications page.
2. Ensure you don’t have unauthorized identity providers (Security > Identity Providers.) For authorized identity providers:
   • Add a suffix to the IdP username format to prevent name duplication, except when using AD as the authentication source.
   • Ensure “Only allow usernames that match defined RegEx Pattern” is checked.
3. If you have a SCIM application installed, verify that the SCIM server is using an encrypted protocol (HTTPS). If not, user data is susceptible to interception. The configured server base URL can be found by selecting the SCIM app on the Applications page, navigating to the Provisioning tab, and then clicking Integration under Settings.
4. Collect and centralize Okta audit logs, and perform threat hunting on a regular basis.

---

Related Resources