Okta’s Investigation of the January 2022 Compromise

Post by Beltiras » Wed, Mar 23, 2022, 10:33 AM UTC

kerng wrote: post #29

Buttons840 wrote: post #10

Earlier quoted context omitted.

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.

Agreed. It's obvious that lawyers are deeply involved already at this point. The most likely reason they dont wanna use the common sense term "breached" is because it implies legally a breach of contract, which means liability and getting sued and having to show up in front of congress. Very sad to see their response be so intransparent and flawed. I wish technical people would be more involved in writing these respo…

Post by JshWright » Wed, Mar 23, 2022, 10:46 AM UTC

thesimon wrote: post #54

a-dub wrote: post #31

Earlier quoted context omitted.

> A person who should not have had access to the system gained near full admin access for five whole days. "This is an application built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles. They are unable to create or delete users. They cannot download customer databases." not being able to create or delete users seems a far cry from…

Why? We only know that they are not able to create new users. But at least changing passwords of existing accounts seemed possible according to the screenshots, perhaps disabling 2FA as well. As long as Okta does not provide a list of what the user was able to do, we don't know

Post by JshWright » Wed, Mar 23, 2022, 10:51 AM UTC

_sword wrote: post #62

caffeine wrote: post #41

Earlier quoted context omitted.

Nope. You are just not understanding it. To simplify: The hackers had minimal access to stuff and couldn’t do much.

They could see the names and contacts of employees at Okta’s customers and reset their credentials at a bare minimum per the leaked screenshot. That doesn’t seem that minimal?

Post by snowwolf » Wed, Mar 23, 2022, 11:01 AM UTC

snowwolf wrote: post #55

qbasic_forever wrote: post #8

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…

> Support engineers use a number of customer support tools to get their job done including Okta’s instances of Jira, Slack, Splunk, RingCentral, and support tickets through Salesforce. I like how it just glosses over access to all the other tools which often contain a treasure trove of data. Just Slack can give an attacker worst case credentials pasted into channels and best case loads of information for more targete…

Post by h0l0cube » Wed, Mar 23, 2022, 11:21 AM UTC

sascha_sl wrote: post #69

h0l0cube wrote: post #61

Earlier quoted context omitted.

> an unauthorized user had full super user access to the service From the article: > The majority of support engineering tasks are performed using an internally-built application called SuperUser or SU for short, which is used to perform basic management functions of Okta customer tenants. This does not provide “god-like access” to all its users. This is an application built with least privilege in mind to ensure tha…

From circulating screenshots, and the omission in the listing here, it looks like they used this account to reset user passwords and MFA on a bunch of tenants. Not being able to create or delete users is meaningless.