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

31–40 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#31

Post by a-dub »

qbasic_forever wrote: post #26
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…

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 "near full admin access."

Re: Okta’s Investigation of the January 2022 Compromise

#34

Post by EMIRELADERO »

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.

Re: Okta’s Investigation of the January 2022 Compromise

#35

Post by shbooms »

ZeroCool2u wrote: post #3

"Although that individual attempt was unsuccessful, out of an abundance of caution, we reset the account and notified Sitel who engaged a leading forensic firm to perform an investigation." Really don't like that they're still unwilling to actually say the name of the 'leading forensic firm'.

All while happily throwing Sitel under the bus.

This whole communication from Okta is a total debacle. They are trying desperately to under play the event and deflect blame in the poor transparency after the event all while not once mentioning that they plan on making any remediations or changing anything in their day to day operations after this incident to prevent it from happening again.

Re: Okta’s Investigation of the January 2022 Compromise

#36

Post by philjohn »

"were taken from a Sitel support engineer’s computer upon which an attacker had obtained remote access using RDP. This device was owned and managed by Sitel. The scenario here is analogous to walking away from your computer at a coffee shop"

It really is not analogous at all.

That RDP was enabled, let alone could be accessed from outside the network is worrying.

To me this would appear that, to save a buck, they outsource a lot of functions that then meant customer security was partly out of their hands, and relied upon another company having their security ducks in a row. I'm sure in their marketing materials they boast about state-of-the-art security, but that's only as good as the weakest point in the chain.

Re: Okta’s Investigation of the January 2022 Compromise

#37

Post by philjohn »

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.

It could be argued that if you don't care about your customers, you won't be in business long enough to please your shareholders.

Re: Okta’s Investigation of the January 2022 Compromise

#38

Post by oxfordmale »

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.

Of course the sole purpose of a publicly traded company is to maximise the revenue for its shareholders, however, you can take a long term or short term approach on this.

Okta appeared to have kept this under wraps to prevent a shareholders backlash (short term approach) However, as a result they achieved the opposite, as the share price is still down this morning. This may of course be a temporarily glitch, however, I can see it resulting in a temporary loss of revenue. If I would be evaluating Okta versus a different solution right now, this may well sway my decision.

Re: Okta’s Investigation of the January 2022 Compromise

#39

Post by cowsup »

qbasic_forever wrote: post #26
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…

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.

The linked article states that SuperUser is the name of their internal software. It's a confusing name, but at no point did the attacker have access to "near full admin access", based off the report.

Re: Okta’s Investigation of the January 2022 Compromise

#40

Post by nstart »

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 Sintel employees. Were any of them sensitive?

The tool doesn't allow them to create or delete users. Does it allow them to modify users so that an attacker can take over an account?

The attacker had access to "Jira, Slack, Splunk, RingCentral, and support tickets through Salesforce". Doesn't sound bad on its own but have those tools been evaluated to ensure they don't have sensitive information? Do we know what the Sintel employee in question accessed from each of those tools for the time period?

The employee's machine was logged into using an RDP session. Was the employee's machine assessed to ensure they weren't storing other sensitive information? While not allowed, a lot of support engineers will quickly drop in "temporary" sensitive stuff into random notepads and what not. Was this assessed? Also, why does a support engineer have a machine that has the ability to enable an inward bound RDP session at all?? How was that not the first trigger since this is a known attack vector for support agents.

Given the possibly small blast radius of this issue, Okta had all the opportunity to turn this into a communications win for them and just build a multiple of trust really quickly. All these half communications have utterly botched it and that's just really disappointing. We'll still continue to use them because the switching costs just don't justify moving off Okta. But Okta has really taken a hit in their "trust bank".

Post reply on HN