When KrebsOnSecurity broke the information on Oct. 20, 2023 that identification and authentication big Okta had suffered a breach in its buyer assist division, Okta mentioned the intrusion allowed hackers to steal delicate information from fewer than one p.c of its 18,000+ prospects. But right this moment, Okta revised that influence assertion, saying the attackers additionally stole the title and e-mail tackle for almost all of its buyer assist customers.
Okta acknowledged final month that for a number of weeks starting in late September 2023, intruders had entry to its buyer assist case administration system. That entry allowed the hackers to steal authentication tokens from some Okta prospects, which the attackers may then use to make adjustments to buyer accounts, akin to including or modifying licensed customers.
In its preliminary incident reviews concerning the breach, Okta mentioned the hackers gained unauthorized entry to information inside Okta’s buyer assist system related to 134 Okta prospects, or lower than 1% of Okta’s buyer base.
But in an up to date assertion printed early this morning, Okta mentioned it decided the intruders additionally stole the names and e-mail addresses of all Okta buyer assist system customers.
“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 mentioned that for almost 97 p.c of customers, the one contact info uncovered was full title and e-mail tackle. That means about three p.c of Okta buyer assist accounts had a number of of the next information fields uncovered (along with e-mail tackle and title): final login; username; cellphone quantity; SAML federation ID; firm title; job position; person sort; date of final password change or reset.
Okta notes that a lot of the uncovered accounts belong to Okta directors — IT individuals liable for integrating Okta’s authentication expertise inside buyer environments — and that these people ought to be on guard for focused phishing assaults.
“Many users of the customer support system are Okta administrators,” Okta identified. “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 could appear utterly bonkers that some firms enable their IT employees to function company-wide authentication methods utilizing an Okta administrator account that isn’t protected with MFA, Okta mentioned absolutely six p.c of its prospects (greater than 1,000) persist on this harmful follow.
In a earlier disclosure on Nov. 3, Okta blamed the intrusion on an worker who saved the credentials for a service account in Okta’s buyer assist infrastructure to their private Google account, and mentioned it was doubtless these credentials had been stolen when the worker’s private gadget utilizing the identical Google account was compromised.
Unlike normal person accounts, that are accessed by people, service accounts are principally reserved for automating machine-to-machine features, akin to performing information backups or antivirus scans each evening at a specific time. For this cause, they’ll’t be locked down with multifactor authentication the way in which person accounts can.
Dan Goodin over at Ars Technica reckons this explains why MFA wasn’t arrange on the compromised Okta service account. But as he rightly factors out, if a transgression by a single worker breaches your community, you’re doing it unsuitable.
“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 prompt that individuals who need to delve additional into varied approaches for securing service accounts ought to learn this thread on Mastodon.
“A fair number of the contributions come from security professionals with extensive experience working in sensitive cloud environments,” Goodin wrote.