Okta Suffers Another Breach

Okta Faces Another Security Breach in Customer Support Unit

Update October 23, 2023 - Added blog post from 1Password Update October 28, 2023 - Added blog post from Wired

Recently reported by KrebsOnSecurity, Okta experienced a security breach targeting its customer support unit. Attackers exploited a stolen credential to access Okta’s support case management system, potentially viewing sensitive files uploaded by certain clients. Although Okta asserts that a minimal number of customers were affected, it’s concerning to note that the intruders had access for approximately two weeks before containment.

While the impact seems to be minimal, this is not the first time Okta has been compromised through their support system, which it seems is either entirely or at least mostly outsourced. In January 2022 there was a similar breach, outlined in this blog post -

Okta Concludes its Investigation Into the January 2022 Compromise

Unfortunately, from their “Lessons Learned” section they specifically mention the following -

Third-party risk management:

Okta is strengthening our audit procedures of our sub-processors and will confirm they comply with our new security requirements. We will require that sub-processors who provide Support Services on Okta’s behalf adopt “Zero Trust” security architectures and that they authenticate via Okta’s IDAM solution for all workplace applications.

While it’s difficult to know for sure, it doesn’t seem like this was actually done given the current breach.

Cloudflare was specifically targeted in both cases once Okta was compromised, which makes sense given how impactful it would be if you could successfully use Okta to gain access to privileged accounts within Cloudflare. In both cases, Cloudflare’s internal security practices prevented the compromise, and in both cases they wrote some good blog posts about how they were able to prevent access.

January, 2022 -

Cloudflare’s investigation of the January 2022 Okta compromise

And October 2023 -

How Cloudflare mitigated yet another Okta compromise

In the October 2023 post, it is clearly much more pointed, and you can see their frustration leaking through, I think with good cause.

Recommendations for Okta

We urge Okta to consider implementing the following best practices, including:

  • Take any report of compromise seriously and act immediately to limit damage; in this case Okta was first notified on October 2, 2023 by BeyondTrust but the attacker still had access to their support systems at least until October 18, 2023.
  • Provide timely, responsible disclosures to your customers when you identify that a breach of your systems has affected them.
  • Require hardware keys to protect all systems, including third-party support providers.

For a critical security service provider like Okta, we believe following these best practices is table stakes.

On the surface, this may seem harsh, but for an identity provider like Okta, it is absolutely critical that they are following the strictest security standards, and they can’t cut corners at all. If an attacker is able to compromise an identity provider like that, that’s essentially the keys to the kingdom. Cloudflare is right, Okta absolutely needs to do better.

While Okta addresses this directly in their post, honestly it seems a tiny bit tone deaf, and kind of underplays the whole situation -

Tracking Unauthorized Access to Okta’s Support System

Unfortunately they spend the majority of the article explaining why it isn’t that big of a deal, then seem to kind of pivot toward “This is why our customers need to be vigilant, and watch for suspicious activity”

Attacks such as this highlight the importance of remaining vigilant and being on the lookout for suspicious activity. We are sharing the following Indicators of Compromise to assist customers who wish to perform their own threat hunting activity. We recommend referring to our previously published advice on how to search System Log for any given suspicious session, user or IP. Please note that the majority of the indicators are commercial VPN nodes according to our enrichment information.

Yes, customers need to be vigilant, and should be looking for suspicious activity, but this was Okta’s fault, not their customers. They need to do a better job of owning up to that, and a better job of communicating. More than anything, they absolutely need to tighten up their security internally. This kind of thing cannot be happening to a company that is built on trust.

Here is BeyondTrust’s article about discovering the compromise - Okta Support Unit Breach

I am a big fan of Okta. Their product is great and in my opinion they are the clear leader in the identity provider space, which is becoming more crucial for companies as a core pillar of your cybersecurity posture. But the more this kind of thing happens, it’s difficult to trust them, and without trust, it won’t really matter how good the product is.


Update - October 23, 2023 - 1Password posted a blog post indicating that they were one of the customers who was accessed because of this breach.

Blog post - Okta Support System incident and 1Password

While it looks like 1Password was able to shut this down during the recon phase, and seemingly nearly immediately, and confirm that none of their internal systems or customer systems were accessed, this reiterates why companies like Okta need to be as bullet proof as possible. If an attacker was able to compromise Okta, then compromise companies like Cloudflare or 1Password, there is an unbelievable amount of damage that could be done.

Update - October 28, 2023 - Article from Wired about the breach. This contains several more quotes

Blog Post - Okta’s Latest Security Breach Is Haunted by the Ghost of Incidents Past

Jake Williams (a former NSA hacker) seems to echo the sentiment I was trying to convey about Okta’s blog post -

“Okta’s suggestion—that somehow the customer must be responsible for stripping session tokens from the files they specifically request for troubleshooting purposes—is absurd,” he says. “That’s like handing a knife to a toddler and then blaming the toddler for bleeding.”