Live data from Hacker News

Okta’s Investigation of the January 2022 Compromise

okta.com

41–50 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#41

I don't understand how the CSO can write this: "In this post, I want to provide a timeline and my perspective on what has transpired, and where we are today with this investigation. I hope that it will illuminate why I am confident in our conclusions that the Okta service has not been breached and there are no corrective actions that need to be taken by our customers." And then go on to write paragraphs of detail and…

Nope. You are just not understanding it.

To simplify: The hackers had minimal access to stuff and couldn’t do much.

Re: Okta’s Investigation of the January 2022 Compromise

#42

> This is an application built with least privilege in mind Uh huh, makes sense > Named SuperUser Uhh... It lists all the operations that it can't do, but not what it can do. Can they download a private SAML certificate? Can they impersonate a user? Can they configure SSO and MFA settings? Can they download audit logs?

> Can they download a private SAML certificate? Oh, that's a good one. Definitely something that the software should not allow, because I can't see a legitimate reason for this (allowing to download the certificate is fine, but not the key).

This was my topmost question too. The report very cleanly omits any and all mentions of SAML signing certificates.

Solar Winds was the first known incident to escalate to so called "Golden SAML" attack. If the support staff had access to signing certificates, then that would open the door to a wide-scale exploitation of Okta's clients.

A shower of Golden SAMLs, if you like.

Re: Okta’s Investigation of the January 2022 Compromise

#45
> The sharing of these screenshots is embarrassing for myself and the whole Okta team.

It speaks volumes that their embarrassment is so important that it was the second sentence of the whole investigation, while there is literally not a single word of apology to the actual customers who were compromised.

Re: Okta’s Investigation of the January 2022 Compromise

#46
So if I'm reading this right, Okta was aware of a "compromise" of one of their sub-processors that impacted an unknown number of their customers/end users. They then waited more than 2 months before performing their own rudimentary analysis of the audit log to see what actions that sub-processor may have taken during the "compromise".

Their CSO writes, "Over the past 24 hours we have analyzed more than 125,000 log entries to ascertain what actions were performed by Sitel during the relevant period. We have determined that the maximum potential impact is 366 (approximately 2.5% of) customers whose Okta tenant was accessed by Sitel."

IANAL and these are only my opinions but it seems like:

(a) Their DPO chose not to notify (GDPR Art. 33) without having the full picture or thought waiting several months for sub-processor's report was a justifiable reason for delaying notification

(b) They failed to perform their own basic forensic activities in light of a "compromise" and only reviewed logs on March 22nd

(c) Have terrible taste in naming their support app "Super User"

In my opinion they are also down playing the importance of the data that may have been compromised. For example do the hackers now know which accounts have MFAs attached to and which don't. What the password policies are (e.g. strength, number attempts, etc.)

Re: Okta’s Investigation of the January 2022 Compromise

#47

I don't understand how the CSO can write this: "In this post, I want to provide a timeline and my perspective on what has transpired, and where we are today with this investigation. I hope that it will illuminate why I am confident in our conclusions that the Okta service has not been breached and there are no corrective actions that need to be taken by our customers." And then go on to write paragraphs of detail and…

Sounds like the main point of disagreement is the definition of a single word, "breached". Otherwise, everyone is in agreement about what happened, right? I agree with your definition of the word for whatever it's worth. At this point, it would be helpful for Okta to stop using the term "breached", because apparently they aren't using the word in the same way everyone else is, and it's a point of contention.

I actually think the definitional conflict might be on the term "Okta service" -

> the Okta service has not been breached

If you consider the Okta service as the infrastructure acutally providing auth services to customers - then it wasn't breached. Only Okta support services were breached and that did not (going with Okta's line here) actually allow for somebody to access the actual Okta auth services.

Re: Okta’s Investigation of the January 2022 Compromise

#48
post #9

What a weird and potentially misleading statement. * They stress that the compromised account wasn't able to "create/delete users or download customer databases", but not what it could do. Could it change passwords of accounts and add 2fa methods, allowing them to take over rarely/never accessed users? Disable 2fa? Change account permissions? List user accounts and metadata to build a user account DB for further atta…

> Sounds a lot like damage control.

Yup, the first line made my hackles stand up; surely there's no security incidents raised for a user-invoked operation like adding MFA to a subcontractor's account? Audit logging is fine, but that's a user-initiated operation that already requires (if they have their shit in order) username, password, existing MFA if applicable, and an e-mail confirmation. To the user. It's all by the user.

Does Github raise the alarms if I change something in my MFA settings?

Re: Okta’s Investigation of the January 2022 Compromise

#49

I don't understand how the CSO can write this: "In this post, I want to provide a timeline and my perspective on what has transpired, and where we are today with this investigation. I hope that it will illuminate why I am confident in our conclusions that the Okta service has not been breached and there are no corrective actions that need to be taken by our customers." And then go on to write paragraphs of detail and…

I think you have misunderstood at least parts of it.

"superuser" is a tool which can be used for various tasks. It is not the same thing as "full super user access". As I understand it, the tool superuser doesn't allow you to do whatever you want, like accessing any piece of data in the databases. It is used by their support engineers.

Not trying to say there was no impact, but "full super user access" traditionally implies more than being able to run one specific tool with the name superuser.

I think people who have written about this and looked at the screen shots has been sloppy and spread misinformation.

Re: Okta’s Investigation of the January 2022 Compromise

#50
post #40

The entire message has a tone of being entirely true but not representative of the entire truth. And that just leaves us all hanging with more questions because it doesn't tell us what we really need to know. 2.5% of all customers were accessed by all Sintel employees for the period in question. How many customers did the particular affected Sintel employee access? They assessed all the actions that took place by the…

LAPSUS$ has stated that Okta had sensitive info in Slack, including AWS Keys (they also confirmed they had access to 8.6K channels).
Post reply on HN