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

51–60 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#51

Post by insickness »

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…

The CSO is implying that the super user was able to get into the system but did not have access to sensitive data, or at least did not exfiltrate that data. It's possible if their defenses are layered enough. The security model is defense in depth, rather than the "moat" concept of hard on the outside, soft on the inside. Micro-breaches are expected; it's about detecting and mitigating them. I'm not saying the CSO is telling the truth, but that's how you reconcile someone having access to the system without accessing sensitive data.

Re: Okta’s Investigation of the January 2022 Compromise

#52

Post by oefrha »

rstat1 wrote: post #14
oefrha wrote: post #5

> 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. Pretty ominous name. I wouldn’t hand out “super user” accounts to support engineers from contracting firms for “basic duties in handling inbound support queries”.

Unless there's some amount of "lying-by-omission" going on here (or some amount of me not understanding what was said), it doesn't sound like support staff get actual super user access to me. It just sounds like a poorly named internal app.

That’s what I meant by ominous.

Re: Okta’s Investigation of the January 2022 Compromise

#53

Post by throw1230 »

Cthulhu_ wrote: post #48
the_duke wrote: 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…

It looks like it's got flagged because the key was added from a new location

Re: Okta’s Investigation of the January 2022 Compromise

#54

Post by thesimon »

a-dub wrote: post #31
qbasic_forever wrote: post #26

Earlier quoted context omitted.

A person who should not have had access to the system gained near full admin access for five whole days. That is the textbook definition of a breach of security. It doesn't matter if they did it by fooling or paying a low level CS rep to get access to their account vs. using their 'leet hacking skillz' to pwn the electronic defenses. A breach is a breach and the CSO of all people has to own up to that fact.

> 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

Re: Okta’s Investigation of the January 2022 Compromise

#55

Post by snowwolf »

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 targeted social engineering attacks. LAPSUS$ even stated they had access to over 8K channels.

Re: Okta’s Investigation of the January 2022 Compromise

#57

Post by chippiewill »

jbrownbridge wrote: post #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 en…

The compromised tenant looks like it was specifically _not_ one of the EMEA ones so GDPR wouldn't be relevant here.

Re: Okta’s Investigation of the January 2022 Compromise

#58

Post by angryGhost »

PixelPaul wrote: post #23

What the best free place to subscribe to, to get notified of hacks like this? Some place that is quick at getting them added/listed and notifying people. As I often hear about it in the news first which is day+ after it’s released and not soon enough

I'd say twitter perhaps but you have to follow the right sources

Re: Okta’s Investigation of the January 2022 Compromise

#60

Post by EwanToo »

chippiewill wrote: post #57
jbrownbridge wrote: post #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 en…

The compromised tenant looks like it was specifically _not_ one of the EMEA ones so GDPR wouldn't be relevant here.

If the tenant had 1 or more European employees in their system, then yes GDPR is likely relevant.
Post reply on HN