Okta: Breach Affected All Customer Support Users

When KrebsOnSecurity broke the news on Oct. 20, 2023 that identity and authentication giant Okta had suffered a breach in its customer support department, Okta said the intrusion allowed hackers to steal sensitive data from fewer than one percent of its 18,000+ customers. But today, Okta revised that impact statement, saying the attackers also stole the name and email address for nearly all of its customer support users.

Okta acknowledged last month that for several weeks beginning in late September 2023, intruders had access to its customer support case management system. That access allowed the hackers to steal authentication tokens from some Okta customers, which the attackers could then use to make changes to customer accounts, such as adding or modifying authorized users.

In its initial incident reports about the breach, Okta said the hackers gained unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers, or less than 1% of Okta’s customer base.

But in an updated statement published early this morning, Okta said it determined the intruders also stole the names and email addresses of all Okta customer support system users.

“All Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor),” Okta’s advisory states. “The Auth0/CIC support case management system was also not impacted by this incident.”

Okta said that for nearly 97 percent of users, the only contact information exposed was full name and email address. That means about three percent of Okta customer support accounts had one or more of the following data fields exposed (in addition to email address and name): last login; username; phone number; SAML federation ID; company name; job role; user type; date of last password change or reset.

Okta notes that a large number of the exposed accounts belong to Okta administrators — IT people responsible for integrating Okta’s authentication technology inside customer environments — and that these individuals should be on guard for targeted phishing attacks.

“Many users of the customer support system are Okta administrators,” Okta pointed out. “It is critical that these users have multi-factor authentication (MFA) enrolled to protect not only the customer support system, but also to secure access to their Okta admin console(s).”

While it may seem completely bonkers that some companies allow their IT staff to operate company-wide authentication systems using an Okta administrator account that isn’t protected with MFA, Okta said fully six percent of its customers (more than 1,000) persist in this dangerous practice.

In a previous disclosure on Nov. 3, Okta blamed the intrusion on an employee who saved the credentials for a service account in Okta’s customer support infrastructure to their personal Google account, and said it was likely those credentials were stolen when the employee’s personal device using the same Google account was compromised.

Unlike standard user accounts, which are accessed by humans, service accounts are mostly reserved for automating machine-to-machine functions, such as performing data backups or antivirus scans every night at a particular time. For this reason, they can’t be locked down with multifactor authentication the way user accounts can.

Dan Goodin over at Ars Technica reckons this explains why MFA wasn’t set up on the compromised Okta service account. But as he rightly point out, if a transgression by a single employee breaches your network, you’re doing it wrong.

“Okta should have put access controls in place besides a simple password to limit who or what could log in to the service account,” Goodin wrote on Nov. 4. “One way of doing this is to put a limit or conditions on the IP addresses that can connect. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.”

Goodin suggested that people who want to delve further into various approaches for securing service accounts should read this thread on Mastodon.

“A fair number of the contributions come from security professionals with extensive experience working in sensitive cloud environments,” Goodin wrote.