|
Getting your Trinity Audio player ready...
|
Welcome to the first installment of our blog series on attack techniques within Okta. Okta is an identity management service that establishes the foundations of secure connection between people and any applications and/or devices. Okta centralizes all applications to login via one identity, which makes user and organizational life simpler and more efficient. In addition, Okta improves the user lifecycle and automates onboarding and offboarding processes.
But as critical as it is to millions of organizations, it has been in the news more than a bit lately.
In October 2023, the company experienced a security incident within its support case management system. Initially, the company said the incident only impacted a limited number of customers. But in November, they disclosed that all Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers had been affected. And the attack continues to have a ripple effect, with third parties being breached via stolen credentials harvested in the Okta breach. The company has experienced multiple other security issues in the past as well.
This is why if your organization is like the millions of others out there using Okta, it’s a good idea to be aware of the potential attack techniques attackers may try to leverage when targeting users.
In this blog series, we’ll cover many attack techniques we have discovered and mapped over the course of our research here at XM Cyber. This series is broken into 3 parts. In this first blog, we’ll provide an overview of Okta’s fundamental components and dive into each part of its environment. In the following blogs, we’ll explore ways in which attackers can escalate their privileges by using the Okta RBAC (Role-Based Access Control) module. It is important to understand that these attacks do not leverage code vulnerabilities; rather, they take advantage of misconfigurations done by IT staff. In the last part of this series, we will describe ways to mitigate those misconfiguration.
Okta Fundamentals
The primary purpose of Okta is to provide organizations with a comprehensive identity and access management (IAM) solution. Okta allows businesses to effectively manage user identities, authentication, and authorization across various applications and systems. It simplifies user onboarding, and provides secure access to resources.
In addition to its core IAM functionality, Okta offers seamless integration with leading cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). This integration enables organizations to manage user access and permissions for cloud-based services in a centralized manner, ensuring consistent security across their cloud environments.
Okta also integrates with Active Directory (AD), allowing organizations to extend their existing AD infrastructure to the cloud. This integration enables users to access both on-premises and cloud resources using a single set of credentials. It streamlines user management, eliminates the need for separate account management in AD and Okta, and enables unified identity and access control across the hybrid environment.
Let’s define and explain about some key terms in Okta:
Okta Tenant
In Okta, the term “tenant” is commonly referred to as an “org” (organization). An Okta org serves as the central hub for managing user identity and access management within your application. It encompasses various components such as user stores, connection management, and profile mapping. Essentially, your Okta org functions as a platform to authenticate your users and facilitate their access to your application.
Users (People)
The term Okta “users” refer to individuals who have user accounts within the Okta Identity and Access Management platform. These accounts are created and managed by administrators to grant users access to various applications and resources.
Okta users have unique identifiers and associated attributes such as username, email address, and profile information. Additionally, users have the ability to belong to groups within Okta and associate their Devices (Factors) for authentication purposes. Moreover, users can be assigned to Admin Roles that grant them specific permissions to perform actions within the Okta tenant.
Groups
In Okta, groups are a way to organize and manage users based on common (Profile) attributes or shared access requirements. Groups allow administrators to effectively assign permissions, policies, and access controls (Admin Role) to multiple users at once. By placing users (People) in groups, administrators can streamline user management and simplify the assignment of resources (Application) and permissions.
Groups can be created based on specific organizational units, departments, roles, or any other criteria that make sense for your organization. Additionally, the group has the capability to define which Directories (such as Active Directory, LDAP servers, and other cloud-based directories) will function as the source of truth. Users can be assigned to one or multiple groups, allowing them to inherit the associated settings and permissions assigned to that group.
Now, if we step into the role of the attacker, we need to know the following about group:
- There are several types of Groups such as “native okta groups”, “application groups” and more. For more information, go to Okta documentation about Okta group source types.
- In a case where we assigned any Admin Role to the Group, only the Super Admin standard role can manage the Group.
- Groups can be assigned to applications that are associated with cloud provider integration applications. In this scenario, if we efficiently manage and escalate our privileges within these groups, we can potentially move laterally to the cloud provider. By doing so, we can access certain roles associated with the cloud provider’s Identity.
Application
Okta applications refer to the integration of external software or services with the Okta platform. Essentially, Okta acts as a central hub to manage user access and authentication for these applications.
By integrating applications with Okta, organizations can streamline user access and enforce strong security measures. Users can log in to multiple applications using a single set of credentials through Okta’s Single Sign-On (SSO) functionality. This simplifies the user experience and eliminates the need to remember multiple usernames and passwords.
Administrators can easily configure and manage application access permissions, assign users (Assignments), and enforce security policies (Authentication Policies) through the Okta Admin Console, and set the scope of permissions for access tokens.
Okta supports a wide range of applications, including popular cloud-based SaaS applications, on-premises applications, and custom-built applications. Moreover, Okta supports importing users from the integrated app and provisioning Okta users and Groups to the SaaS application environment such as AWS, Entra ID, and GCP (Google Cloud Provider).
Additionally, Okta provides features such as Multi-Factor Authentication (MFA) to add an extra layer of security for accessing applications. It also offers integrations with various identity protocols, such as SAML, OAuth, and OpenID Connect (Sign-On), to ensure seamless and secure communication between Okta and the applications.
If a custom application exists within the Okta tenant, it has the potential to assist an attacker in creating an access token that would grant them access to Okta resources through the API. Furthermore, if the Okta administrator has configured permissive “API Scopes”, it could allow the attacker to perform additional actions using the same access token.
Global Session Policy
Global Session Policy in Okta is a feature that allows administrators to define and enforce specific policies regarding user sessions across the Okta platform. It enables administrators to set rules and controls that govern how long user sessions are active and what actions can be performed during those sessions.
With the Global Session Policy, administrators can specify session duration limits, idle timeouts, and conditions for user session termination. This helps improve overall security by automatically logging users out after a specified period of inactivity or when a session exceeds its allowed duration.
Additionally, administrators can configure actions to be taken when a session is terminated, such as displaying a custom message or redirecting users to a specific page. This allows organizations to personalize the user experience while ensuring compliance with security policies.
Authentication Policy
Authentication Policy refers to the set of rules and controls that administrators can define to regulate the authentication process for users accessing the Okta platform and its integrated applications.
With the Authentication Policy, administrators can enforce specific requirements and conditions for user authentication. This may include factors such as password complexity, the use of multi-factor authentication (MFA), geographic location restrictions, device trust, and more. By configuring these policies, organizations can enhance security and protect against unauthorized access.
Administrators can create different authentication policies based on user groups, applications, network zones, or other criteria to tailor the authentication requirements to specific user segments or application contexts. This allows for flexibility in applying the appropriate level of security based on user roles or specific application needs.
Default Install Apps
In Okta, there are default applications that come within the Okta tenant:
- Okta Admin Consoles – The Okta Admin Console is a web-based application that provides administrators with a centralized interface to manage and configure the Okta identity and access management platform.
- Okta Dashboard – The Okta Dashboard is an application that displays the applications associated with a user and provides notifications to the user.
- Okta Browser Plugin – The Okta Browser Plugin enables users to utilize single sign-on (SSO) for applications that do not support Security Assertion Markup Language (SAML) for user credentials. It can be configured for users within your organization, including your own administrator account.
- Okta Workflow – Okta Workflows simplify the automation of identity processes on a large scale, eliminating the need for coding. Leveraging if-this-then-that logic, pre-built connectors in Okta’s library, and compatibility with various public APIs, it empowers users to innovate with Okta.
Role Based Access Control (RBAC)
Okta utilizes roles as a fundamental component of its RBAC model for managing user access and permissions. Roles define privileges and permissions that can be assigned to users or groups within the Okta tenant environment. Administrators can easily configure roles by specifying names and descriptions, and by assigning specific privileges.
Roles play a crucial role in controlling user access to resources like applications, directories, and administrative settings. By assigning roles, administrators can grant or restrict access to different functionalities and data within Okta. Roles in Okta are highly customizable, allowing administrators to define granular permissions for capabilities such as user management, group management, application access, and system configuration.
Okta supports dynamic role assignments based on user attributes or group memberships, automating role assignments and simplifying access management for large organizations. Additionally, Okta integrates with applications, enabling roles to be mapped and synchronized with roles or groups in connected applications. This ensures consistent and synchronized access control across both Okta and the integrated applications.
In Okta, we have two main types of Roles.
- Standard Role
- Custom Role
Standard Role
Okta provides a set of standard roles that are predefined and offer predefined sets of permissions for various administrative tasks and access control within the Okta platform. These standard roles serve as a starting point for configuring user access and provide a foundation for implementing Role-Based Access Control (RBAC) in Okta.
Here’s a table that shows all the standard roles that are offered by Okta.
| Role Name | Role Type | Optional Targets |
| API Access Management Administrator | API_ACCESS_MANAGEMENT_ADMIN | |
| Application Administrator | APP_ADMIN | Apps |
| Group Membership Administrator | GROUP_MEMBERSHIP_ADMIN | Groups |
| Help Desk Administrator | HELP_DESK_ADMIN | Groups |
| Organizational Administrator | ORG_ADMIN | |
| Read-only Administrator | READ_ONLY_ADMIN | |
| Super Administrator | SUPER_ADMIN | |
| Group Administrator | USER_ADMIN | Groups |
| Custom Label specified by the client | CUSTOM | Groups |
Custom Role
Custom admin roles gives you the ability to configure granular permissions within a role.
This feature offers:
More control over creation of roles in a self-service way. You can create custom role assignments based on your specific use case. You can assign granular permissions to your admins in a way that only gives them permissions that they need to perform a task. This reduces the need to assign the super admin and org admin roles to your users. It also helps simplify admin audits and compliance reviews with more visibility over granular admin permissions.
An admin role assignment consists of these three components:
- Admin – The user, user group, or app that you need to grant admin permissions to. In Okta terminology, any standard or custom role may also be also known as an “admin role”, and for that all users that associate with the “admin role” can be called admin, even if the custom role does not contain “Super Administrator” privileges.
- Role – A set of permissions that you constrain an admin to. There are two types of roles, standard and custom. You can create a maximum of 100 roles for an org. Currently, permissions are limited to managing user, group, and app activity, and running profile source imports.
- Resource set – A collection of resources. You can create a maximum of 10,000 resource sets and assign a maximum of 1,000 resources for each resource set. Currently, only user groups and apps in your org are considered to be resources.
For more information about Roles:
Permission
Permissions are typically assigned to roles rather than directly to individual users. This follows the RBAC (Role-Based Access Control) model. Users are assigned roles, and these roles have associated permissions. This approach simplifies access management because you can assign and manage permissions at the role level, making it easier to maintain access control as your organization evolves.
For more information about okta permissions:
Factor
In the Okta environment, a factor refers to a device used by users during the 2FA login process. Each factor is assigned a name and ID and can be modified or removed by privileged users.
Okta offers two main ways to configure 2FA authentication:
- Global Session Policy – When the rule inside the Global session policy is configured for the Multifactor authentication (MFA) to be required, configuring a factor becomes necessary for accessing any application within Okta. This ensures the implementation of 2FA. Additionally, if a user utilizes the “Authentication API”, they will be required to complete the 2FA authentication process in order to get a valid session token.
- Authentication Policies – In this level of authentication, IT managers have the ability to grant specific permissions for applications such as the Okta dashboard or Okta Admin. However, in this case, 2FA is not mandatory globally. Users who use the Okta “Authentication API” will receive a valid session token to perform actions without UI authentication.
Authentication Ways in Okta
In Okta, there are three (3) main ways to authenticate against the web UI and the Okta API:
- SSWS Token
- Access Token
- Session ID (sid)
SSWS Token
SSWS (Session-Specific Web Service) token is a type of access token used in the Okta API. It is a secure and time-limited token that authenticates and authorizes API requests on behalf of a user or application. SSWS tokens are used in API requests to authenticate and authorize access to Okta’s resources, such as user profiles, groups, applications, and other data. These tokens provide a secure means of accessing protected resources while ensuring that the user’s session remains secure.
The following users are able to create this token.
The following pictures shows how you can create API Tokens via the “Okta Admin console”
As an attacker, SSWS Tokens are the best way to authenticate and interact against resources in your Okta tenant.
Access Token
The Okta access token is used to access protected resources, such as APIs, that are hosted on the Okta platform. It is a bearer token, which means that whoever has the token can access the resources that the token authorizes. Therefore, it is essential to keep the token secure and avoid sharing it with unauthorized parties. In addition, each access token has a scope parameter that gives the access token the ability to perform action in your Okta tenant. For instance, we can set a scope of managing users by adding the “okta.users.manage” to the scope and then to manage users with this access token. In addition, in Okta, the super administrator can set Okta API Scopes that define the scope of the access token you create in the OAuth authentication process.
Note: In Okta, only super administrators can edit and read “OKTA API Scopes”.
For more information about how to create access tokens, check out the following link:
Session ID
Okta session ID is a unique identifier assigned to a user’s session after the user logs into Okta. This ID is used to keep track of the user’s session and identify the user’s session when the user interacts with Okta. Okta session ID is a combination of letters and numbers, which is generated by Okta when the user logs in. The session ID is stored in a cookie in the user’s web browser. The session ID is sent with each subsequent request made by the user to Okta. This allows Okta to identify the user’s session and provide the user with access to the appropriate resources. In order to create a Session ID, you can find more information in the following link:
Summary
Okta is a widely adopted Identity Provider (IDP) environment known for its integration with robust management tools and capabilities. Recognizing the security attributes of the Okta environment is crucial for safeguarding Okta-based deployments.
Stay tuned for parts 2 and 3 of this series, where we’ll address the attack techniques you need to be aware of and how to mitigate them.
FAQ
How did XM Cyber identify and map the specific attack techniques within the Okta environment that are discussed in this series?
XM Cyber identified and mapped the specific attack techniques within the Okta environment discussed in the series by conducting in-depth security assessments and analysis of Okta environments. This involved exploring and exploiting various vulnerabilities and misconfigurations in Okta’s Role-Based Access Control (RBAC) and other components. They likely utilized a combination of manual testing, automated tools, and their expertise in cybersecurity to discover how attackers could leverage weaknesses to escalate privileges, gain unauthorized access, and move laterally within a network. Their research and findings are often shared through detailed blog posts or reports, aiming to raise awareness and help organizations strengthen their security posture.
Are there any real-world examples or case studies where these misconfigurations in Okta’s RBAC (Role-Based Access Control) module led to significant security breaches or incidents?
Regarding real-world examples or case studies, while the specific details of incidents related to misconfigurations in Okta’s RBAC leading to security breaches are not always publicly disclosed, there have been several high-profile breaches where identity and access management systems played a role. For instance, in various instances, attackers have exploited misconfigurations and weaknesses in identity management systems to perform credential stuffing attacks, gain unauthorized access to sensitive systems, or escalate their privileges within a network. These incidents underline the importance of properly configuring and managing access controls to protect against unauthorized access and potential data breaches.
Aside from misconfigurations by IT staff, are there other common vulnerabilities or weaknesses within the Okta environment that attackers commonly exploit, and will those be covered in future blog posts?
Aside from misconfigurations by IT staff, other common vulnerabilities or weaknesses within the Okta environment that attackers commonly exploit include vulnerabilities in third-party applications integrated with Okta, phishing attacks targeting Okta users to steal credentials, and exploiting outdated or weak protocols. Attackers may also target API keys or tokens that are not securely managed, as well as taking advantage of any lack of multifactor authentication on critical accounts. XM Cyber and other security researchers are likely to cover these and other vulnerabilities in future blog posts, as part of their ongoing efforts to educate and inform about cybersecurity risks and how to mitigate them. Continuously identifying and addressing new vulnerabilities is crucial for maintaining the security of Okta environments and protecting sensitive information.
Related Topics
){kind=icon}
){kind=icon}
){kind=icon}
){kind=icon}
){kind=icon}