Okta, a leading provider of authentication services and Identity and Access Management (IAM) solutions, says that its private GitHub repositories were hacked this month.
According to a ‘confidential’ email notification sent by Okta and seen by BleepingComputer, the security incident involves threat actors stealing Okta’s source code.
Source code stolen, customer data not impacted
BleepingComputer has obtained a ‘confidential’ security incident notification that Okta has been emailing to its ‘security contacts’ as of a few hours ago. We have confirmed that multiple sources, including IT admins, have been receiving this email notification.
Earlier this month, GitHub alerted Okta of suspicious access to Okta’s code repositories, states the notification.
“Upon investigation, we have concluded that such access was used to copy Okta code repositories,” writes David Bradbury, the company’s Chief Security Officer (CSO) in the email.
Despite stealing Okta’s source code, attackers did not gain unauthorized access to the Okta service or customer data, says the company. Okta’s “HIPAA, FedRAMP or DoD customers” remain unaffected as the company “does not rely on the confidentiality of its source code as a means to secure its services.” As such, no customer action is needed.
At the time of writing our report, the incident appears to be relevant to Okta Workforce Identity Cloud (WIC) code repositories, but not Auth0 Customer Identity Cloud product, given the email wording.
An excerpt from the remainder of the notification, reviewed by BleepingComputer, is published below:
As soon as Okta learned of the possible suspicious access, we promptly placed temporary restrictions on access to Okta GitHub repositories and suspended all GitHub integrations with third-party applications.
We have since reviewed all recent access to Okta software repositories hosted by GitHub to understand the scope of the exposure, reviewed all recent commits to Okta software repositories hosted with GitHub to validate the integrity of our code, and rotated GitHub credentials. We have also notified law enforcement.
Additionally, we have taken steps to ensure that this code cannot be used to access company or customer environments. Okta does not anticipate any disruption to our business or our ability to service our customers as a result of this event.
Note: The security event pertains to Okta Workforce Identity Cloud (WIC) code repositories. It does not pertain to any Auth0 (Customer Identity Cloud) products.
We have decided to share this information consistent with our commitment to transparency and partnership with our customers.
While ending its ‘confidential’ email that pledges a ‘commitment to transparency,’ Okta says it will publish a statement today on its blog.
BleepingComputer reached out to Okta with questions in advance of publishing but a reply was not immediately available.
Okta security incidents: year in review
It’s been a difficult year for Okta with its series of security incidents and bumpy disclosures.
September this year, Okta-owned Auth0 disclosed a similar-style incident. According to the authentication service provider, older Auth0 source code repositories were obtained by a “third-party individual” from its environment via unknown means. But, Okta’s problems began long before, amid the irregularity surrounding the disclosure of its January hack.
March this year, data extortion group Lapsus$ claimed it had access to Okta’s administrative consoles and customer data as it began posting screenshots of the stolen data on Telegram.
After stating that it was investigating these claims, Okta shortly acknowledged that the hack being referred to had in fact occurred late January 2022 and potentially affected 2.5% of its customers. This figure was estimated to be roughly 375 organizations at the time, given Okta’s 15,000+ customer base back then.
The same week, Okta admitted that it had “made a mistake” in delaying the disclosure of this hack that, the firm said, had originated at its third-party contractor, Sitel (Sykes).
In April, Okta clarified that the January breach had lasted “25 consecutive minutes” and the impact was significantly smaller than what was originally anticipated: limited to just two customers.