Threat Modeling the Okta Attack

Threat Modeling the Okta Attack

Okta’s customer support system was attacked, allowing the attackers to access Okta customer systems. This was possible because the Okta customer support system contained HAR files and these include customer session data. The customer session data allowed for session hijack attacks.

HAR files (short for HTTP Archive) are archives of web browser sessions, including cookies and session tokens.

The attacker was able to gain access to the Okta customer support system because an employee stored a service account password in their personal Google account, which was compromised by the attacker.

According to Okta, 5 customers had hijacked sessions, allowing for unauthorized access for the attackers, out of 134 customers affected by the compromise of the Okta customer support data.

The attack was widely reported in the media.

Sources:

Note: This threat modeling analysis is based on publicly available information. Publicly available information may differ from what actually occurred. Further, new information may be disclosed as it is discovered and published.

The key takeaway: Organizations must understand that when using outsourced solutions such as Okta, they are not only depending on their technology but also their people and processes. This attack shows that multiple weaknesses were abused leading to unauthorized access to Okta customer systems.

Background

Okta provides identity and access solutions to its 18,000+ customers. The services provided by Okta include multi-factor authentication (MFA), cloud identity, password-less solutions, Single Sign On (SSO), and more.

Given Okta’s services, any attacks or data breaches are very sensitive for Okta customers, because it may in turn lead to unauthorized access to their systems.

Threat Modeling Diagram and Key Components Involved

Okta threat modeling diagram

Key actors/components:

Company Laptop with Google Account / Chrome Browser: These components were used by the Okta employee to save the credentials of a service account on a third-party service (Google account).

Attacker: The attacker used the stolen service account credentials to access the customer support system for further attack.

Customer Support System: The customer support system stores information from customer support calls & sessions. Employees asked customers to send HAR files, which were stored in the customer support system.

HAR Files / Customer Sessions: The HAR files contained (some) active session data, which the attacker could use to gain unauthorized access to customer systems.

The Threats (or Weaknesses) Exploited in the Data Breach

The attacker was able to gain access to the Okta customer support system using credentials stored in a personal Google account. Using the customer support system, the attacker was able to gain unauthorized access to some customer systems.

Threats or weaknesses exploited:

  • The Okta employee was able to access a personal Google account via a corporate laptop.
  • The service account credentials of the customer support system were accessible to the Okta employee and used in an unsanctioned way (sharing it with a personal Google account).
  • Okta support employees asked customers to share HAR files without removing session data.
  • The customer support system was accessible to the attacker (so probably available via the internet, and not to employees only).
  • Okta was not able to detect suspicious activity that was ongoing for weeks, which was successfully identified by some of its customers.

Potential Countermeasures (or Security Requirements)

The following countermeasures or security requirements would (partially) mitigate the threat:

  • Block access to websites and services that can be used to share confidential company data in an unsanctioned way (i.e., Gmail, Hotmail, Google Documents, and similar services).
  • Develop secure practices for handling service accounts and other secrets, including the use of vaults/safes.
  • Do not ask customers to share confidential data (such as session tokens), and do not store confidential customer data unless absolutely necessary.
  • Limit availability of internal applications to employees only where possible.
  • Implement security logging & monitoring that is able to detect suspicious behavior and activity.

The Threat Actor(s)

The threat actor (or attacker) has the following characteristics:

  • External – No access to internal systems and no access to internal employees.
  • Technically proficient – The threat actor was able to target the employee rather than Okta directly. Once credentials were gained, the threat actor was able to target Okta customers.
  • Motivated by gaining access to customers – The Okta service has the potential to open up thousands of its customers.

Connect with me

Enter your Email address if you want to connect and receive threat modeling updates (I won’t spam you or share your contact details).

AND / OR

Try my threat modeling tool, it's completely free to use.

Thanks for signing up!