Hacker News Reader

Comment by koolba | Hacker News Reader

> 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 action is needed may be a stretch.

View on HN

> This means they could have reset anybody’s credentials and logged in

Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

The text is a bit ambiguous (and probably on purpose, I'm sure it passed through multiple layers where multiple lawyers have reviewed it too). Okta says Lapsus$ were unable to "obtain" the passwords, but they didn't say they were unable to set their own passwords (for example). Neither is the MFA tokens mentioned, although they do mention MFA in the text.

Then they'd have obtained it, no?

It seems pertinent a support engineer could trigger a password reset if they were worried a password had been compromised for a user.

I think "obtain" here is specifically meant to mean "get existing passwords in plaintext", not "get a valid password via resetting it to a known one".

> Then they'd have obtained it, no?

If you change a password, then you didn't "obtain" the previous password. Weasel words but there you go.

What if they have access to some users' emails and then can selectively fire off password reset emails to them? It's probably less likely, but could be a vector.

They wouldn't need to have an Okta CSE account for that, since anyone can go to *.okta.com and fire off a reset password email for any account. (Then again it does look like that's not available for every org. There's not a "reset password" option on cloudflare.okta.com for instance. Why give a CSE the option to do a password reset in those cases, though?)

It still sounds to me like they're saying that they could set the password on an account to anything they wanted, but not retrieve an existing password.

This would be a big red flag to anyone who's observant and realizes that their password had been changed, but plenty of people would probably simply take it in stride and reset their password thinking they'd forgotten it. Either way the horse is out of the barn.

I don't understand all these crazy assumptions being made. A support engineer being able to set a password on any account is unthinkable, there is zero chance this is actually the case. Especially for a security company. It would be the equivalent of giving the doorman a key that opens everyone's apartment. Obviously support can trigger a reset, that you have to complete from your own e-mail account.

Confusing analogy, doormen frequently do have a key to every apartment in the building.

Anyway I agree it would be bad practice but that doesn't mean it's not done.

> doormen frequently do have a key to every apartment in the building

Really? That's insane. I'd like to hear more about that.

I've actually had a landlord give the keys to one of the tenants since they didn't have a doorman. The tenant in question was actually a registered sex offender too, but the judge is friends with the landlord so no harm done. Crazy world.

> A support engineer being able to set a password on any account is unthinkable, there is zero chance this is actually the case

I have no idea what an Okta support engineer can or can't do but I know that a regular account administrator can set an arbitrary password for a given user via the Okta UI.

> What if they have access to some users' emails

Then those users are hosed anyway? They could always trigger a normal user-facing password reset email without any access to support systems.

Can't you request a reset without any special access? Many (but not all) applications have a publicly accessible log in page with a "Forgot your password?" link that takes an email as input.

I think the original reason I posed the question is because I used Okta a while back for one org and IIRC there was no password reset available to me; I had to contact one of our IT admin to do it.

If they have access to some users' emails, they wouldn't need access to okta to reset the password and take control of the account. If a hacker has access to your email then you've already been pwnd.

That's pretty common and wouldn't lead to a compromise. It's a potential DOS vector, yes, but not a compromise. However, I wonder if Okta tech support is also able to change a user's registered email...

If OKTA gates email like at most organizations, reset email doesn't work. It has to be the ability to set a temp password.

It's been a minute since I was an admin in an Okta directory, but don't all resets use a self-service flow? In order to log in to someone's account, I think you need to compromise their email, too.

They do indeed use a self-service flow.

Super admins can set a temporary password. But they can also change a user's email address, disable password and email change notifications, lock out all other admins... They have complete control of the org.

It's pretty clear there is no super admin breach here. None of the screenshots show an admin interface - the app portal shot clearly shows a distinct lack of the "Admin" button. No user directory shots. There is a single image of a password reset confirmation, but those are also in documentation so it's hardly a smoking gun.

It seems far more likely that a support engineer had their laptop compromised and their limited access was used to try and make a mountain out of a molehill. Not like a ransomware group would have reason to over-exaggerate their access and ability, right?

Okta engineers stored some of their AWS keys in Slack. Depending on what those were the keys to it could be REALLY bad.

Off the top of my head: direct database access, http server - could push compromised pages to all Okta users

The AWS keys really could be the keys to the whole proverbial kingdom.

FWIW organisation size of Okta probably has hundreds if not thousands of AWS keys. We really won't know which keys were that.

Do you have a reference for this? Thanks.

Password reset requests still go to your registered email.

Do you know if Okta support are/were able to change a user's email?

You can indeed change the email / login on a user's profile an an org admin, but we probably won't know if Okta support agents themselves can also do that.

besides the whole "we dug through slack and got your AWS keys" i think the worst case scenario would have been removing MFA from an a compromised account and having access to the e-mail to self-serve the password reset.

that and maybe going through JIRA and seeing if anything was of any interest?

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.

Reply on news.ycombinator.com