Omar Marques/SOPA Images/LightRocket via Getty Images
Identity and authentication management provider Okta released an autopsy report Friday on a recent breach that gave hackers administrative access to some of its customers’ Okta accounts. While the autopsy highlights the violations of an employee logging into a personal Google account on a work device, the biggest contributing factor was something the company underplayed: a poorly configured work account.
In a post, Okta Chief Security Officer David Bradbury said the threat actor behind the attack most likely gained access to parts of his company’s customer support system by first compromising an employee’s personal device or personal Google account and then moving out from there The username and password for a special type of account, called a service account, used to connect to the support segment of the Okta network. Once the threat actor had access, he was able to obtain administrative credentials to access the Okta accounts of 1Password, BeyondTrust, Cloudflare, and other Okta customers.
Passing the buck
“During our investigation into suspicious use of this account, Okta Security discovered that an employee had signed in to his personal Google profile in the Chrome browser of his Okta-managed laptop,” Bradbury wrote. “The service account username and password were stored in the employee’s personal Google account. The most likely path for these credentials to be exposed is by compromising the employee’s personal Google account or personal device.”
This means that if the employee logged in to the account in Chrome while it was authenticated to the personal Google account, the credentials were most likely stored in that account via Chrome’s built-in password manager. After the personal account or device was compromised, the threat actor then obtained the necessary credentials to access the Okta account.
It has long been known that accessing personal accounts at a company like Okta is a big no-no. And if this prohibition was not clear to some before, it should be clear now. The employee has almost certainly violated company policy, and it would not be surprising if the violation resulted in the employee’s termination.
However, it would be wrong to conclude that employee misconduct was the cause of the breach. That wasn’t it. Instead, the fault lies with the security people who designed the breached support system, particularly in the way the breached service account was configured.
A service account is a type of account that exists in various operating systems and frameworks. Unlike standard user accounts accessed by humans, service accounts are mostly reserved for automating machine-to-machine functions, such as performing data backups or antivirus scans at a specific time every night. For this reason, they cannot be locked like user accounts with multifactor authentication. This explains why MFA was not set up for the account. However, the breach highlights several errors that did not receive the attention they deserved in Friday’s post.
Memo to the Okta security team
First, in addition to a simple password, Okta should have implemented access controls to limit who or what can log in to the service account. One way to do this is to allowlist a handful of company-controlled IP addresses and block all others unless additional credentials are provided. Another is to periodically rotate the access tokens used to authenticate to service accounts. And of course, it should have been impossible for employees to log into personal accounts on a work computer. These and other precautions are the responsibility of Okta’s senior management.
The security approach known as “zero trust” is sometimes overused, but the principle is sound. Assume that your network has already been attacked and design it so that nothing bad happens anyway. This means that a layered, deep defense method must be deployed to prevent single points of failure such as the compromise of a simple password or authentication token.
Bradbury said Okta first learned of potentially suspicious activity on its network on September 29, when 1Password reported that its Okta instance had been compromised. After initially suspecting the compromise was due to a malware infection on a 1Password employee’s device, Okta learned of the compromise of a new customer account three days later, on October 2, when BeyondTrust reached out. Okta did not identify the cause of the breach until October 16th. The breach allowed the threat actor to maintain access to the service account for more than two weeks.
Bradbury wrote:
When a user opens and views files attached to a support case, a specific log event type and ID associated with that file is generated. If a user instead navigates directly to the Files tab in the customer support system, as the threat actor did in this attack, they will instead generate a completely different log event with a different record ID.
Okta’s initial investigations focused on access to support cases. We then evaluated the protocols associated with these cases. On October 13, 2023, BeyondTrust provided Okta Security with a suspicious IP address that was associated with the threat actor. Using this indicator, we identified the additional file access events associated with the compromised account.
The lack of visibility into Okta’s network is another deficiency that, while not the cause of the breach, made it much worse than it would have been had the access been discovered earlier.
Bradbury implicitly acknowledges some of the shortcomings in the remedial measures outlined in his paper. They include:
1. The compromised service account disabled (completed) Okta has disabled the service account in the customer support system.
2. Block use of Google personal profiles with Google Chrome (full) Okta has implemented a special configuration option in Chrome Enterprise that prevents users from signing in to Chrome on their Okta-managed laptop with a personal Google profile.
3. Advanced customer support system monitoring (completed)
Okta has implemented additional detection and monitoring rules for the customer support system.
4. Binding Okta admin session tokens based on network location (completed)
Okta has released session token binding based on network location as a product enhancement to address the threat of session token theft for Okta administrators. Okta administrators are now forced to re-authenticate when we detect a network change. This feature can be enabled by customers in the Early Access section of the Okta Admin Portal.
Okta deserves credit for making the changes and providing a timeline of events, but assigning responsibility for the breach scapegoats an erring employee, obscuring where the actual error lies. The most serious mistakes were made by people much higher up the seniority ladder. We hope they get the memo.