Omar Marques/SOPA Images/LightRocket via Getty Images
Identity and authentication management provider Okta on Friday published an autopsy report on a recent breach that gave hackers administrative access to the Okta accounts of some of its customers. While the postmortem emphasizes the transgressions of an employee logging into a personal Google account on a work device, the biggest contributing factor was something the company understated: a badly configured service account.
In a post, Okta chief security officer David Bradbury said that the most likely way the threat actor behind the attack gained access to parts of his company’s customer support system was by first compromising an employee’s personal device or personal Google account and, from there, obtaining the username and password for a special form of account, known as a service account, used for connecting to the support segment of the Okta network. Once the threat actor had access, they could obtain administrative credentials for entering the Okta accounts belonging to 1Password, BeyondTrust, Cloudflare, and other Okta customers.
Passing the buck
“During our investigation into suspicious use of this account, Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury wrote. “The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”
This means that when the employee logged into the account on Chrome while it was authenticated to the personal Google account, the credentials got saved to that account, most likely through Chrome’s built-in password manager. Then, after compromising the personal account or device, the threat actor obtained the credentials needed to access the Okta account.
Accessing personal accounts at a company like Okta has long been known to be a huge no-no. And if that prohibition wasn’t clear to some before, it should be now. The employee almost surely violated company policy, and it wouldn’t be surprising if the offense led to the employee’s firing.
However, it would be wrong for anyone to conclude that employee misconduct was the cause of the breach. It wasn’t. The fault, instead, lies with the security people who designed the support system that was breached, specifically the way the breached service account was configured.
A service account is a type of account that exists in a variety of operating systems and frameworks. 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. This explains why MFA wasn’t set up on the account. The breach, however, underscores several faults that didn’t get the attention they deserved in Friday’s post.
