Updated Okta Statement on Lapsus$ • Hacker News Board

Re: Updated Okta Statement on Lapsus$

#61

Post by Consultant32452 » Tue, Mar 22, 2022, 7:13 PM UTC

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…

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.

Re: Updated Okta Statement on Lapsus$

#62

Post by panqueque » Tue, Mar 22, 2022, 7:15 PM UTC

spike021 wrote: post #26

bhaney wrote: post #10

Earlier quoted context omitted.

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

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.

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

Re: Updated Okta Statement on Lapsus$

#63

Post by lnxg33k1 » Tue, Mar 22, 2022, 7:15 PM UTC

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.

I would say it's more about what each entity has at stake, the public company could be read as "An entity which sold something that didn't have the capability to offer and has a lot to lose if the issues are uncovered"

Against "Someone that what has to lose at this point?"

Re: Updated Okta Statement on Lapsus$

#64

Post by gurjeet » Tue, Mar 22, 2022, 7:15 PM UTC

nimbius wrote: post #59

>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. despite an overwhelming preponderance of damning evidence from twitter (as well as the hacker themselves) you've somehow managed to find yourselves secure instead? Christs whiskers thats some impressive doublethink. Its also an excellent opportunity to fall on a sword that giv…

No post body was provided.

Re: Updated Okta Statement on Lapsus$

#65

Post by RL_Quine » Tue, Mar 22, 2022, 7:15 PM UTC

tofuahdude wrote: post #11

> Okta service has not been breached and remains fully operational > 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 These are some impressive mental gymnastics!

Yeah, this blog post is shoveling it. They were popped, they aren't internally consistent in their dismissal of it.

Re: Updated Okta Statement on Lapsus$

#66

Post by Melatonic » Tue, Mar 22, 2022, 7:16 PM UTC

nimbius wrote: post #59

>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. despite an overwhelming preponderance of damning evidence from twitter (as well as the hacker themselves) you've somehow managed to find yourselves secure instead? Christs whiskers thats some impressive doublethink. Its also an excellent opportunity to fall on a sword that giv…

This is going to get interesting in the days ahead

Re: Updated Okta Statement on Lapsus$

#67

Post by Melatonic » Tue, Mar 22, 2022, 7:16 PM UTC

dogecoinbase wrote: post #5

More than a little concerning that they apparently investigated this in January, and while there's a lot of talk about what could or could not have happened, they don't seem to know what actually happened, and no customers were notified (but now: "[we are] identifying and contacting those customers that may have been impacted).

I believe that is because they are now hitting the legal limit of when they are required by law to notify people.

Re: Updated Okta Statement on Lapsus$

#68

Post by allyant » Tue, Mar 22, 2022, 7:17 PM UTC

intunderflow wrote: post #55

intunderflow wrote: post #51

Earlier quoted context omitted.

To note in some of the earlier screenshots you can see they have the EC2 Instances menu open in their tabs - that's a bit concerning, why does a support engineer need AWS EC2 access?

Can you open the web console with just an access key? My impression was you could only use that to act through a CLI tool, at least officially you need to have powers or act as a user with powers to use the web console directly?

Not using access keys- although using the cli you could create a user which does have the ability to login to the portal.

Re: Updated Okta Statement on Lapsus$

#69

Post by duncan-donuts » Tue, Mar 22, 2022, 7:18 PM UTC

smcl wrote: post #7

> In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider It looked kinda successful though...

> 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 consistent with the screenshots that we became aware of yesterday.

Yeah, it was.

Re: Updated Okta Statement on Lapsus$

#70

Post by panqueque » Tue, Mar 22, 2022, 7:19 PM UTC

paxys wrote: post #15

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…

Password reset requests still go to your registered email.

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