Okta Security Blog

Good question.

From their incident report yesterday it looks as though Okta started by blaming the victims, taking half a month to realize Okta itself was the problem. Then they clamped down on Chrome's automatic exfil of company credentials.

https://sec.okta.com/harfiles

That feels narrow.

What seems evident, but not addressed, is their initial reaction of victim customer blaming, the identification of suspicious behavior by multiple different customers before seeing it themselves, and the previous latitude for Chrome, likely trace back to lax culture and behavior, particularly around insider threat: not behaving as if they really believe "the problem is us".

So, address the specific faults as Okta did, but attribute those to a 'root cause' need for a stronger 'security mindset' with active insider threat modeling across all employees and roles, and insider focused detective controls.

Something like, "We spend all our time helping less secure customers level up their security and it's easy to feel good about how much more secure we are than most. But we ourselves don't have to be just better than our customers which probably seems easy. We have to be better than the threats who want to use us against our customers, and that's incredibly hard. Clearly we can do better."

Then double down on security mindset training (for customers to be secure, we have to be secure), and as part of that do comprehensive insider threat modeling and tabletop exercises across roles (even…

There were 3 known customers targeted.

>BeyondTrust reported the issue.

All 3 customers discovered the issue before Okta fixed the issue. I think all 3 reported the issue to Okta before Okta fixed the issue, but I'm not sure. 1Password and BeyondTrust both reported the issue to Okta before Okta discovered the issue (although 1Password wasn't sure whether the cause was a compromise of Okta's support or malware on the laptop; 1Password didn't find malware, but still thought there might be some). I'm not sure whether Cloudflare reported the issue to Okta before Okta fixed the issue, but it seems likely due to timing. Cloudflare was compromised Oct 18 and immediately discovered it, and the very next day Okta fixed the issue, whereas previously the issue had been languishing for 19 days. That seems to indicate to me that Cloudflare reported it to Okta and Okta kicked their incident response into high gear due to Cloudflare's report.

All 3 customers posted blog posts about the issue after Okta posted a blog post about the issue.

The order they were targeted was: 1Password (Sept 29), BeyondTrust (Oct 2), Cloudflare (Oct 18). I think they reported the issues to Okta in that same order (BeyondTrust reported the issue to Okta the same day they were targeted, I'm not sure about 1Password, and as mentioned above, I suspect Cloudflare reported the issue to Okta the same day they were targeted).

The order they posted blog posts about the issue was: Okta, BeyondTrust, Cloudflare,…

> most major websites

Is this true? Do you know of any major ones offhand? That would be surprising to me.

Thanks for sharing [0]. I found its discussion of shared subdomain cookies useful. However, I believe all the vulnerabilities in the OAuth section would be mitigated by using PKCE and not using the implicit flow, even if you leave the open redirect. Am I missing anything there?

As for open redirects in general, it is an important problem. As an authorization server, if you want to protect against clients that might have an open redirect (and as you indicate eventually one will), while still using the simple scheme I mentioned above, I can think of a few options:

1. Require the client_id to exactly match the redirect_uri instead of just a prefix. This is probably the most secure, but can result in ugly client IDs shown to the user, like "example.com/oauth2/callback". Of course clients can control that and make it something prettier if they want.

2. Strip any query params from the redirect_uri, and document this behavior. That should handle most cases, but it's always possible clients implement an open redirect in the path itself somehow. You could also check for strings like "http", but at some point there's only so much you can do.

3. Require clients to implement client metadata[1], so you can get back to exact string matches for redirect_uri. This is a very new standard, and also doesn't work for localhost clients.

[0]:…

Okta recently partnered with a few folks to tackle this. They published a thing [1] in April. Fraudulent registrations and bots are being screened using Shape which was acquired by F5 [2]. I'm not saying this problem has been solved, but it's an area of active concentration. For most folks, the offerings are more than adequate. For the top saas or platforms, you'll probably always have this issue as you're a lucrative target.

[1] https://sec.okta.com/shareddetections

[2] https://www.f5.com/cloud/products/bot-defense

The market has correctly observed that it wasn’t Salesforce who screwed up, it was their customers.

Okta came out and said they were not compromised, despite being targeted.[0]

I assume this is because they did some hardening on their unnamed “support case management system” last time they got popped.[1]

[0] https://cyberscoop.com/okta-zscaler-security-leaders-salesloft-drift-attacks/

[1] https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/