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

21–30 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#21

Post by tgsovlerkhgsel »

bytelines wrote: post #4

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

Re: Okta’s Investigation of the January 2022 Compromise

#22

Post by a-dub »

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 and even audit all activities that have taken place. in other words, the system worked as designed.

this is very different (and orders of magnitude less severe) than an actual compromise of the production service itself.

Re: Okta’s Investigation of the January 2022 Compromise

#24

Post by Closi »

Buttons840 wrote: post #10
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…

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.

Everyone else is using the plain English definition because it’s accurate.

Okta is intentionally using their own definition to down-play what’s happened.

A breach is simply ‘to overcome defences’ (ie to get access to something you shouldn’t). In this case their defence against someone else accessing the super user application was the support employee and their credentials, but this defence was clearly overcome by the hackers.

I agree that they need to stop using the word.

Re: Okta’s Investigation of the January 2022 Compromise

#25

Post by bigDinosaur »

staticassertion wrote: post #17
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.

One company doing a bad job does not mean it's impossible or even uncommon to do a good job. Also, if you wanted to hedge against Okta... feel free. You can U2F 2FA your services behind Okta or in front of it. We use GSuite SSO, but everywhere we can set 2FA outside of it we do so.

While true, Okta isn't some minor player that we can just wave away like this. I bet lots of other similar big companies will have similar issues - this is about much more than just their technical merit.

Re: Okta’s Investigation of the January 2022 Compromise

#26

Post by qbasic_forever »

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…

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.

Re: Okta’s Investigation of the January 2022 Compromise

#27

Post by oxfordmale »

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.

Re: Okta’s Investigation of the January 2022 Compromise

#28

Post by sofixa »

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

Depends on the type of hack. Haveibeenpwned is a classic, but i don't think it covers cases like this, it's more for username/password/PII breaches.

Re: Okta’s Investigation of the January 2022 Compromise

#29

Post by kerng »

Buttons840 wrote: post #10
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…

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 responses, not lawyers.

Re: Okta’s Investigation of the January 2022 Compromise

#30

Post by kerng »

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…

They dont wanna use the word "breached" because lawyers write these things - and legally breach has a different meaning than security wise. Very sad that they already prepare on the legal front rather then being open and transparent.
Post reply on HN