Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Okta’s Investigation of the January 2022 Compromise

okta.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#61

Post by h0l0cube »

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…

> 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 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. They cannot access our source code repositories.

Re: Okta’s Investigation of the January 2022 Compromise

#62

Post by _sword »

caffeine wrote: post #41
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…

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?

Re: Okta’s Investigation of the January 2022 Compromise

#63

Post by zaroth »

bostik wrote: post #42
tgsovlerkhgsel wrote: post #21

Earlier quoted context omitted.

> 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.

Caution to fellow readers: Put down your drink before reading the last line of this post.

Re: Okta’s Investigation of the January 2022 Compromise

#64

Post by chaps »

a-dub wrote: post #22
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…

> And then go on to write paragraphs of detail and a timeline that explicitly shows for a five day period an unauthorized user had full super user access to the service. it sounds like they built the support tool (with its unfortunate name) such that it places limited trust in support contractors and the information technology that supports them. because of this they're able to identify potentially affected customers…

The screenshots by the attacking group claimed to have access to thousands of slack channels, many of which they say included API keys. It's likely that some or many of those were to prod services.

Re: Okta’s Investigation of the January 2022 Compromise

#66

Post by Traubenfuchs »

tl;dr - Companies cheerfully handed over their golden skeleton and city (company) keys over to a third party service provider that offers SSO and now, after they got hacked by some kiddy that writes like a teenager, we found out that they also just cook with water (or less: api keys in slack). Now the public company communication is a reputation crushing web of lies, inaccuracies and whining.

Re: Okta’s Investigation of the January 2022 Compromise

#67

Post by socks »

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

At my own workplace (a SaaS service), we cannot change passwords, we can only send reset links (and the reset email goes to the end user).

I can't see any place in the screenshots where they are setting a user's password, only sending reset links (which would do nothing if the support user does not have access to system email or end users email).

Also at my workplace, 2FA is not enforced by an IdP (like Okta), but by our own application (and therefore could not be disabled at the IdP level).

Re: Okta’s Investigation of the January 2022 Compromise

#68

Post by tyingq »

dordoka wrote: post #50
nstart wrote: 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).

I see a Splunk icon in the app list also, which is often a good source of that sort of thing.

Re: Okta’s Investigation of the January 2022 Compromise

#69

Post by sascha_sl »

h0l0cube wrote: post #61
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…

> 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.

Re: Okta’s Investigation of the January 2022 Compromise

#70

Post by rootlocus »

EMIRELADERO wrote: post #34
oxfordmale wrote: post #27

As communicated in stern words to Okta, my company unnecessarily spend many people hours on this. IT had to investigate if we were impacted by this, and on top of that issued a password reset for the entire company. A swift communication by Okta could have avoided this all together. It seems they care more about their shareholders than their customers.

> It seems they care more about their shareholders than their customers. isn't this how publicly-traded companies are supposed to work ? I agree on critizicing that approach and capitalism model, but I don't understand how that isn't common knowledge here.

Companies who care about their customers usually do better in the long run. You can look up "long term greedy" for an example.
Post reply on HN