Mar 22, 2022 8:13 PM

The Third-Party Okta Hack Leaves Customers Scrambling

Authentication firm Okta's statements on the Lapsus$ breach fails to answer key questions.

The digital extortion group Lapsus$ threw the security world into disarray on Monday with claims that it had gained access to a “super user” administrative account for the identity management platform Okta. Since so many organizations use Okta as the gatekeeper to their suite of cloud services, such an attack could have major ramifications for any number of Okta customers. While Okta has released new details—including clarifying what “super user” means and the potential extent of the breach—questions about the incident, and the company's handling of it, remain unanswered.

Okta said in a short statement early Tuesday morning that in late January it had “detected an attempt to compromise the account of a third-party customer support engineer working for one of our subprocessors,” but that “the matter was investigated and contained by the subprocessor.”

In an expanded statement on Tuesday afternoon, Okta's chief security officer, David Bradbury, said categorically, “The Okta service has not been breached.” The details that have emerged, though, including from Bradbury's statement itself, paint a confusing picture, and the conflicting information has made it difficult for Okta customers and others who depend on them to assess their risk and the extent of the damage.

“There are two big unknowns when it comes to the Okta incident: the specific nature of the incident and how it might impact Okta customers,” says Keith McCammon, chief security officer at the network security and incident-response firm Red Canary. “This is exactly the type of situation that leads customers to expect more proactive notification of security incidents that impact their product or customers.”

On Tuesday evening, about eight hours after posting Bradbury's statement, Okta updated the notice with some expanded information. Specifically, the company admitted that roughly 2.5 percent of its customers “have potentially been impacted,” adding that their data “may have been viewed or acted upon.” In a later update, the company clarified that the “maximum potential impact” of the breach is 366 customers; Okta reported having more than 14,000 customers as of February.

Bradbury's original statement said that the company only received analysis of the January incident this week from the private forensics firm it hired to assess the situation. The timing coincides with Lapsus$'s decision to release screenshots, via Telegram, that claim to detail its Okta administrative account access from late January.

The company's expanded statement opens by saying that it “detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider.” But apparently some attempt was successful, because Bradbury goes on to say that the incident report recently revealed “a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop.”

The statement adds that, during those five days, attackers would have had the full access that support engineers are granted, which does not include the ability to create or delete users, download customer databases, or access existing user passwords but does include access to Jira tickets, lists of users, and, crucially, the ability to reset passwords and multifactor authentication (MFA) tokens. The latter is the main mechanism Lapsus$ hackers would likely have abused to take over Okta logins at target organizations and infiltrate.

Okta says that it is contacting customers who may have been impacted. On Tuesday, though, companies including the internet infrastructure firm Cloudflare raised the question of why they were hearing about the incident from tweets and criminal screenshots rather than from Okta itself. The identity management company seems to maintain, though, that compromising a third-party affiliate in some way is not a direct breach.

“In Okta's statement, they said they were not breached and that the attacker's attempts were ‘unsuccessful,’ yet they openly admit that attackers had access to customer data," says independent security researcher Bill Demirkapi. “If Okta knew since January that an attacker may have been able to access confidential customer data, why did they never inform any of their customers?”

In practice, breaches of third-party service providers are an established attack path to ultimately compromise a primary target, and Okta itself seems to carefully limit its circle of “sub-processors.” A list of these affiliates from January 2021 shows 11 regional partners and 10 sub-processors. The latter group are well-known entities like Amazon Web Services and Salesforce. The screenshots point to Sykes Enterprises, which has a team located in Costa Rica, as a possible affiliate that may have had an employee Okta administrative account compromised. Okta later confirmed the subprocessor as business services outsourcing company Sitel Group, which purchased Sykes in September 2021. Sitel, Okta said, hired a forensic firm to investigate the breach. Okta said it received a summary report about the incident on March 17 but didn't receive the full report until Tuesday afternoon.

Sykes, meanwhile, said in a statement, first reported by Forbes on Tuesday, that it suffered an intrusion in January.

“Following a security breach in January 2022 impacting parts of the Sykes network, we took swift action to contain the incident and to protect any potentially impacted clients,” the company said in a statement. “As a result of the investigation, along with our ongoing assessment of external threats, we are confident there is no longer a security risk.”

The Sykes statement went on to say that the company is “unable to comment on our relationship with any specific brands or the nature of the services we provide for our clients.”

As for the “super user” account Lapsus$ claimed to have accessed, Okta said in an updated statement that SuperUser is an application “used to perform basic management functions of Okta customer tenants,” and doesn't provide “'god mode-like access' to all its users."

On its Telegram channel, Lapsus$ posted a detailed (and frequently self-congratulatory) rebuttal to Okta’s statement.

“The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and [multifactor authentication] would result in complete compromise of many clients systems,” the group wrote. “If you are commited [sic] to transparency how about you hire a firm such as Mandiant and PUBLISH their report?"

For many Okta customers struggling to understand their potential exposure from the incident, though, all of this does little to clarify the full scope of the situation.

“If an Okta support engineer can reset passwords and multifactor authentication factors for users, this could present real risk to Okta customers,” Red Canary's McCammon says. “Okta customers are trying to assess their risk and potential exposure, and the industry at large is looking at this through the lens of preparedness. If or when something like this happens to another identity provider, what should our expectations be regarding proactive notification and how should our response evolve?”

Clarity from Okta would be especially valuable in this situation, because Lapsus$'s general motivations are still unclear.

“Lapsus$ has expanded their targets beyond specific industry verticals or specific countries or regions,” says Pratik Savla, a senior security engineer at the security firm Venafi. "This makes it harder for analysts to predict which company is most at risk next. It's likely an intentional move to keep everyone guessing, because these tactics have been serving the attackers well so far."

As the security community scrambles to get a handle on the Okta situation, Lapsus$ could have even more revelations brewing.

Updated Wednesday March 23, 2022, at 12:20am ET to include expanded comment from Okta including the percentage of customers it says were potentially impacted by the breach.

Updated Wednesday March 23, 2022, at 12:10pm ET to include the exact number of customers that could have been impacted by the breach, new details about the third-party subprocessor whose employee's account was accessed, and assertions from Okta that SuperUser is an application without “god mode-like access" to customer accounts.