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

81–90 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#81

Post by nijave »

I remember a couple years ago we were using Okta for AWS federated access. One day a bunch of role associations disappeared. Ended up badgering support for a couple weeks since the audit logs were empty before they finally admitted it was a "bad migration"

Apparently they had some internal issue with orphaned records or something and deployed a code "fix" that ended up deleting legitimate records in a way that wasn't auditable from the customer side.

I think it took about 4-6 weeks of trying to escalate through support and account reps until we actually got an answer. It was also very surprising to see role associations just disappear without a trace (we associated Okta groups with AWS IAM roles in the Okta integration)

Re: Okta’s Investigation of the January 2022 Compromise

#82

Post by ctvo »

socks wrote: post #67
thesimon wrote: post #54

Earlier quoted context omitted.

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…

Is your workplace Okta? They built a custom internal tool. Until they enumerate exactly what the attacker had access to it’s hard to infer anything.

Re: Okta’s Investigation of the January 2022 Compromise

#83

Post by salmo »

qbasic_forever wrote: post #13
bigDinosaur wrote: post #11

Earlier quoted context omitted.

I view this hack as a public service - we're seeing how awfully these big security companies actually handle security in the worst case. Let that be a lesson to everyone who is in favour of mass centralisation. There needs to be a security solution where Okta essentially provides the skeleton of the infrastructure but not the entire solution, such that an Okta compromise does not compromise everyone who uses them.

It's wild that apparently near full admin access to the service was handed out to subcontractors of subcontractors. There was so little oversight and so many levels of indirection that it took months to figure out the full impact of the breach and incident. This does not seem like a healthy or responsible security policy for a company whose primary business is... authentication security.

No, definitely not full admin access. Just a support tool called “SuperUser”.

It was a customer service rep who could send password reset emails.

Systems listed were that app and SaaS offerings. The laptop was vendor owned and managed.

Given my experience, it probably had 0 access to anything “inside” Okta. There was no mention of vendor VPN or Virtual Desktop access. Or access to any internal system beyond what was a horribly named call center support tool.

They really wouldn’t have passed the necessary audits for their enterprise and government customer base if they allowed 3rd party devices “real” access.

Beyond a “hacker” getting access, there is very little trust in (likely) contract employees of a contract company.

The fact that the tool is named Super User is killing them more than anything here.

Re: Okta’s Investigation of the January 2022 Compromise

#84

Post by a2tech »

qbasic_forever wrote: post #13
bigDinosaur wrote: post #11

Earlier quoted context omitted.

I view this hack as a public service - we're seeing how awfully these big security companies actually handle security in the worst case. Let that be a lesson to everyone who is in favour of mass centralisation. There needs to be a security solution where Okta essentially provides the skeleton of the infrastructure but not the entire solution, such that an Okta compromise does not compromise everyone who uses them.

It's wild that apparently near full admin access to the service was handed out to subcontractors of subcontractors. There was so little oversight and so many levels of indirection that it took months to figure out the full impact of the breach and incident. This does not seem like a healthy or responsible security policy for a company whose primary business is... authentication security.

And don't forget that they meet all the governments BS standards and auditing checks. So lots of government contractors use them.

Re: Okta’s Investigation of the January 2022 Compromise

#85

Post by kasey_junk »

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.

Why is it a meaningless distinction to prevent account creation but allow password reset?

Most commercial services allow unauthenticated password reset just by hitting a web form. It would send a password reset link to the correct place and the person would either ignore it, follow through and have a new password or report it. It doesn’t impact the service access at all.

Meanwhile creating an account would allow new access to the system. I’m having a hard time figuring out how that’s not a world of difference?

Re: Okta’s Investigation of the January 2022 Compromise

#86

Post by kasey_junk »

chaps wrote: post #64
a-dub wrote: post #22

Earlier quoted context omitted.

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

This is the actual egregious thing in the breach. All of the support tool stuff seems like it was acting as designed and prevented the breach for sprawling.

The idea that at a security focused company they are passing around secrets via public slack channels is wild. That’s the thing they need to address.

Re: Okta’s Investigation of the January 2022 Compromise

#87

Post by JohnCClarke »

The first 71 minutes of the response timeline are exemplary. But then two gaps emerge: 1. (Bad) Why did it take an entire day to notify the contractor? 2. (Much, much worse) Why is there no mention of any investigation into all the historical actions taken by that support agent?

Re: Okta’s Investigation of the January 2022 Compromise

#88

Post by numbsafari »

tgsovlerkhgsel wrote: post #20

It's interesting how you need to read what they don't write to actually figure out what they're saying: They are unable to create or delete users. They cannot download customer databases. They cannot access our source code repositories. So they can likely arbitrarily access/impersonate or at least password reset existing users, and probably reconfigure the accounts in creative ways. For transparency, these customers…

At least they are finally notifying.

Re: Okta’s Investigation of the January 2022 Compromise

#89

Post by sb8244 »

ctvo wrote: post #82
socks wrote: post #67

Earlier quoted context omitted.

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…

Is your workplace Okta? They built a custom internal tool. Until they enumerate exactly what the attacker had access to it’s hard to infer anything.

The article specifically addresses this, right? They log every interaction from support engineers and are going to report to the affected customers what actions were performed.

As others have mentioned, the slack access is potentially more concerning.

Re: Okta’s Investigation of the January 2022 Compromise

#90

Post by dfsegoat »

> "I am greatly disappointed by the long period of time that transpired between our notification...once WE received the Sitel summary report WE should have moved more swiftly to understand its implications."

This is an example of total non-ownership. He is the CSO. It should be "I" or "My" and not diffusing responsibility onto his team with "We".

In my book you should celebrate your successes as a team ("we", "our") but failures are ALWAYS on leaders ("I", "my").

Post reply on HN