Okta is identity provider, used by many large enterprises to manage user access to the cloud or on-prem applications or physical devices. Obviously that elevate its attack surface and makes it much more attractive target to go after – once an adversary breaches identity provider or MSP it can go after all their clients.
Unfortunately that was the case in the late September when Okta reported that: “From September 28, 2023 to October 17, 2023, a threat actor gained unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers, or less than 1% of Okta customers”.
Breaches like that need to be handled with care and properly announced to partners and affected parties, since trust can be damaged if communication is lacking or insincerity is sensed. Okta had lost more than $2 billions in its market value since the hack went public. Similarly the recent LastPass breaches and their very poor communication is the reason a lot of cybersecurity professionals advocate against the usage of their services.
Contrary to that, when Solarwinds got breached in 2020, their quick and honest disclosure, in parallel with their collaboration with big companies like Microsoft to deal with the fallout and identify the probable APT (Advanced Persistent Threats) helped them a lot with their public image and did not damage their market share as much in long term.
How did it happen?
The initial reports were that Okta’s customer support system was taken advantage of, namely by leveraging stolen credentials of a service account. According to Okta the username and password of that service account that had the permissions to access files uploaded by Okta customers were saved into personal Google account of an employee (using Okta-managed laptop) and eventually leaked.
Most likely these credentials were exposed on less secure device where the same user was logged in and they were synchronized. Since that gross overlook of BYOD policy Okta also have updated their internal rules and technical controls of using personal accounts on company’s machines and BYOD policy.
Five major companies were affected and three of them have written openly about the fallout of the Okta compromise on their systems:
Cloudflare, 1Password, and BeyondTrust.
Method of compromise of third parties
Part of the usual troubleshooting in Okta is that Okta clients upload HAR files (HTTP archive) – basically offline copy of the current browser session. It contains all that is necessary to establish valid connection to the servers in questions, including session tokens or cookies.
Soon after the upload of the HAR file to Okta an access attempt to the BeyondTrust Okta admin console was made but it was denied due to increased security posture of BeyondTrust.
Several other attempts were made using the API of the admin console and using the official API the adversary succeeds to create rogue service account masquerading like real ones (using similar naming scheme).
Regardless the BeyondTrust security teams seem to act faster than the attackers disabling the service account and mitigating the attack.
In their blog they detail the steps needed to be taken to secure Okta accounts and the Okta admin dashboards and API to avoid default attacks. They also include Indicators of Compromise.
Clouldflare have also blogged about their incident response and also have emphasized the usage on Data Loss Prevention system that would stop leaking of sensitive tokens and authentication cookies to third parties from corporate managed machines.
1Password have published their Security incident report detailing their investigation and steps tracing the suspicious activity and their estimation of the level of penetration. They also have isolated the machine from which the HAR file was uploaded, took it offline and scanned it with malware scanner. They have not discovered any more suspicious activity originated from this user account.
Previous Okta breaches
In March 2022 Okta was compromised again. First news about the breach was released in Twitter where screenshots with their clients information, namely Cloudflare. It seemed that again support account was compromised with access to tools like reset passwords or disable/modify the MFA Cloudflare forced password reset to most of its employees. Unlike the current breach which was taking part for more than 3 weeks this one was resolved in less than 5 hours.
Lessons learned
- Employment of stricter BYOD policy must be enforced.
- Data Loss Prevention system for critical endpoints must be enabled.
- Personal and Corporate accounts should not be mixed on single browser (better even no personal accounts should exist on corporate machine).