I don't understand how OKTA is +4.34%/1M and 10.26%/5D. This is bat-shit crazy lol. Anyway I put a 10,000USD 5x sell at 166.19, let's see how it goes from here :D :D :D
hahha. downvote at will. I just made $2k with literally twenty mouse clicks.
Okta’s Investigation of the January 2022 Compromise
101–110 of 124 posts
Re: Okta’s Investigation of the January 2022 Compromise
#102Earlier 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 password reset considered a big issue? If I know your email / login I can go reset your password for a bunch of stuff now without any breach.
Re: Okta’s Investigation of the January 2022 Compromise
#103I'm curious about Okta's customer facing audit logs. It seems they do offer audit logs [1] [2] but I can't find the documentation on what all events are included and if actions by support are (which they should). Google for example includes transparency events in it's audit log [3], CloudTrail also shows actions taken by AWS support.
I've talked about this before [4] but just having internal audit logs doesn't cut it nowadays, even in this case it took two months to check the audit logs, you should give your customers access to their audit logs, ideally in near realtime so they can do proactive monitoring.
[1] https://help.okta.com/en/prod/Content/Topics/Reports/Reports...
[2] https://developer.okta.com/docs/reference/api/system-log/
[3] https://developers.google.com/admin-sdk/reports/v1/appendix/...
[4] https://apptrail.com/blog/2022/03/07/internal-vs-customer-fa...
Re: Okta’s Investigation of the January 2022 Compromise
#104I 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.
Was coming around to make this point that in the cybersecurity world the word "breach" can have a very particular meaning with legal implications. As a cybersecurity professional, we are trained not to refer to anything as a breach while communicating findings of investigations or alerting organizations to activities that we see unless that has already been legally established.
There is plenty concerning about their response to this situation, and this phrasing can be confusing, but from my POV in the industry this choice of words is understandable.
Re: Okta’s Investigation of the January 2022 Compromise
#105I'm curious about Okta's customer facing audit logs. It seems they do offer audit logs [1] [2] but I can't find the documentation on what all events are included and if actions by support are (which they should). Google for example includes transparency events in it's audit log [3], CloudTrail also shows actions taken by AWS support. I've talked about this before [4] but just having internal audit logs doesn't cut it…
Apparently support actions can be found with "user.session.impersonation" from what I read.
Re: Okta’s Investigation of the January 2022 Compromise
#106Earlier 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.
[deleted]
Re: Okta’s Investigation of the January 2022 Compromise
#107What 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…
The MFA tokens you use on Github are provided by you. The MFA tokens used by Okta employees/contractors may be provided by Okta, therefore Okta may know the token that was attempted to be added was not provided by them, and that is why it may have been blocked and a security alert generated. GitHub can't do that unless they are the only ones providing the tokens to their users.
Re: Okta’s Investigation of the January 2022 Compromise
#108Earlier 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…
How do you send a reset password email with a SSO platform that gates email?
Re: Okta’s Investigation of the January 2022 Compromise
#109Earlier quoted context omitted.
> 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.
No, it is not how publicly traded companies are supposed to work. Publicly traded companies can set whatever priorities they want; the law only requires certain levels of accurate reporting. If shareholders think a company is too focused on customers, or not enough on shareholders, their options are simply to complain or sell the stock, or both.
They can vote for different board members or do shareholder initiatives as well.
Re: Okta’s Investigation of the January 2022 Compromise
#110Earlier 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 relevant question is "near-full admin access of a system that does what?"
If Okta has implemented a BeyondCorp model, the attackers had access with known limits. It doesn't matter how much access if the machine they've accessed is itself untrusted. That's the punchline of an episode of Star Trek: Lower Decks where they allowed an evil computer to take over the lighting systems on a starship; while they repaired the ship, all the computer could do was flick the lights on and off angrily.