3 ms·

It’s actually comical that Cloudflare is trying to blame Okta for this. A Cloudflare employee uploaded secrets to Okta’s support tool. That is what caused the b

It’s actually comical that Cloudflare is trying to blame Okta for this. A Cloudflare employee uploaded secrets to Okta’s support tool. That is what caused the breach.

ethbr1 3y ago
>> It appears that in our case, the threat-actor was able to hijack a session token from a support ticket which was created by a Cloudflare employee. It's the same type of session replay attack (likely HAR) discussed in the original article, no? It seems a reasonable expectation to assume that anything sent to Okta support isn't instantly available to attackers. So, yes, valid session tokens were dumb. But also yes, Okta fucked up here too.
- 4death4 3y ago
  > It seems a reasonable expectation to assume that anything sent to Okta support isn't instantly available to attackers. No that’s not a reasonable assumption. Malicious Okta employee is just as significant an attack vector as compromised Okta support tool.
  - ethbr1 3y ago
    'Malicious Okta employee' who already has privileged access in the systems the customer has chosen to outsource their auth to? If Okta employee is a high priority threat model... then the customer is better off not using Okta. Not that it shouldn't be considered, but if Okta top-to-bottom penetration is expected and accepted, then that's taking Zero Trust to a whole new length.
NicoJuicy 3y ago
What? What screwed thinking is that? It's literally a policy from Okta to investigate issues, which isn't Cloudflare's fault. The tool from Okta got compromised and all clients that needed support from Okta could/have been damaged as well. Additionally, it was Cloudflare that SAW something was off and notified Okta. Cloudflare didn't get breached at all. > The root cause is that Okta got compromised. It's even suprising that Cloudflare's policies are so good in detection that they detected this at all, before Okta.

It’s actually comical that Cloudflare is trying to blame Okta for this. A Cloudflare employee uploaded secrets to Okta’s support tool. That is what caused the breach.

ethbr1 3y ago

>> It appears that in our case, the threat-actor was able to hijack a session token from a support ticket which was created by a Cloudflare employee. It's the same type of session replay attack (likely HAR) discussed in the original article, no? It seems a reasonable expectation to assume that anything sent to Okta support isn't instantly available to attackers. So, yes, valid session tokens were dumb. But also yes, Okta fucked up here too.

4death4 3y ago
> It seems a reasonable expectation to assume that anything sent to Okta support isn't instantly available to attackers. No that’s not a reasonable assumption. Malicious Okta employee is just as significant an attack vector as compromised Okta support tool.
- ethbr1 3y ago
  'Malicious Okta employee' who already has privileged access in the systems the customer has chosen to outsource their auth to? If Okta employee is a high priority threat model... then the customer is better off not using Okta. Not that it shouldn't be considered, but if Okta top-to-bottom penetration is expected and accepted, then that's taking Zero Trust to a whole new length.

NicoJuicy 3y ago

What? What screwed thinking is that? It's literally a policy from Okta to investigate issues, which isn't Cloudflare's fault. The tool from Okta got compromised and all clients that needed support from Okta could/have been damaged as well. Additionally, it was Cloudflare that SAW something was off and notified Okta. Cloudflare didn't get breached at all. > The root cause is that Okta got compromised. It's even suprising that Cloudflare's policies are so good in detection that they detected this at all, before Okta.