Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Updated Okta Statement on Lapsus$

okta.com

Post reply on HN
Print view View original

41–50 of 239 posts

Re: Updated Okta Statement on Lapsus$

#41

Post by mdoms »

phphphphp wrote: post #20
chockchocschoir wrote: post #6

> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit. What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned…

what I don’t get is, if support can’t do anything but “reset” which doesn’t expose the ability to gain access… how is support helping users? If a user can access their email, then they can reset themselves — surely? The idea that support can just trigger a reset email makes little sense. Perhaps Okta has some complex mechanisms that I am not aware of, but if this was any system I’ve ever worked on, an employee could…

You should do a stint in support. You'd be amazed how many people would rather interact with support than click the Forgot Password link.

Re: Updated Okta Statement on Lapsus$

#43

Post by evan_ »

chockchocschoir wrote: post #37
lalopalota wrote: post #28

Earlier quoted context omitted.

It is not ambiguous. Facilitate means help. If a user cannot trigger the reset, support engineers can (help them) do it.

In what way would a Okta user be unable to trigger the reset while a support engineer could? If they are unable to access the Okta website where the password reset gets initiated, they are also unable to access the very same Okta website where the new password would be set. And why use the more general word of "facilitate" when they could have been specific and say "trigger reset password flow" or similar. Hence thei…

It looks like there are some orgs where "forgot password" is restricted and has to go through an internal site admin- or an Okta CSE. There's not a "Reset password" link on cloudflare.okta.com for instance, just a link to contact their internal support.

Regardless, "reset" can mean different things and it definitely seems like they're being cagey here by intentionally using imprecise language.

Re: Updated Okta Statement on Lapsus$

#45

Post by lalopalota »

chockchocschoir wrote: post #37
lalopalota wrote: post #28

Earlier quoted context omitted.

It is not ambiguous. Facilitate means help. If a user cannot trigger the reset, support engineers can (help them) do it.

In what way would a Okta user be unable to trigger the reset while a support engineer could? If they are unable to access the Okta website where the password reset gets initiated, they are also unable to access the very same Okta website where the new password would be set. And why use the more general word of "facilitate" when they could have been specific and say "trigger reset password flow" or similar. Hence thei…

User's laptop is lost / stolen. User notifies supervisor. Supervisor (with admin authority on the account) notifies okta support and asks that the password be reset.

Re: Updated Okta Statement on Lapsus$

#46

Post by Fabricio20 »

jgrahamc wrote: post #2

Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...

> Suspend the one Cloudflare account visible in the screenshots

As far as I can see, there's a lot of cloudflare accounts visible in the screenshots shared by the group. Stuff like cloudflaretv1, etc..

Re: Updated Okta Statement on Lapsus$

#47

Post by mdoms »

koolba wrote: post #4

> Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. This means they could have reset anybody’s credentials and logged in. There would a record of it if the audit logs are valid, but saying no act…

No it doesn't. The password reset email goes to the user's registered email address and the link can't be obtained by support.

Re: Updated Okta Statement on Lapsus$

#48

Post by warp »

vault wrote: post #17
mimikatz wrote: post #8

I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is cons…

If somebody uses my laptop, my Gmail account is not compromised; I'm being dolphined. Of course 5 days is quite a long time, but this is just to clarify what you didn't understand.

"had access to a support engineer’s laptop" is very vague, they could have:

  1. some kind of remote access to the support engineer's session on that laptop
  2. physical access, no login
  3. physical access as a different user
  4. physical access, logged in as the support engineer
If I have access to your laptop, logged in as you, and you have Gmail open in a browser, then your Gmail account should be considered compromised. (e.g. I could set up a forwarding address in your Gmail settings, set up a POP/IMAP password, steal your session/remember me cookies, install some dodgy software which makes sure I have remote access to your laptop in the future, etc..).

Re: Updated Okta Statement on Lapsus$

#49

Post by MrStonedOne »

Johnny555 wrote: post #34
skilled wrote: post #9

I mean, ultimately, it is now up to Lapsus$ to confirm this. If everything they say (and the Cloudflare post, also) is true then I don't think anyone should be worried.

It's an interesting world we live in if the word of an organization that earns a living by stealing data and extorting companies is trusted more than the word of a public company.

No post body was provided.

Re: Updated Okta Statement on Lapsus$

#50

Post by phphphphp »

mdoms wrote: post #41
phphphphp wrote: post #20

Earlier quoted context omitted.

what I don’t get is, if support can’t do anything but “reset” which doesn’t expose the ability to gain access… how is support helping users? If a user can access their email, then they can reset themselves — surely? The idea that support can just trigger a reset email makes little sense. Perhaps Okta has some complex mechanisms that I am not aware of, but if this was any system I’ve ever worked on, an employee could…

You should do a stint in support. You'd be amazed how many people would rather interact with support than click the Forgot Password link.

As much as I’d like to forget, I’ve done a lot of support and much of that was authentication issues. I can certainly imagine in a corporate environment that some contingent of users would prefer to be hand-held through the reset request process, but all of them?

My expectation (and experience of other similar systems) was that Okta would not allow password resets by anyone but the organization administrators. However, that doesn’t appear to match up with what has been disclosed here.

Post reply on HN