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

231–239 of 239 posts

Re: Updated Okta Statement on Lapsus$

#231

Post by spike021 »

giaour wrote: post #38
spike021 wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: Updated Okta Statement on Lapsus$

#232

Post by nickcox »

ricardobeat wrote: post #139
evan_ wrote: post #32

Earlier quoted context omitted.

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…

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.

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

Re: Updated Okta Statement on Lapsus$

#233

Post by dang »

Related ongoing thread:

New Updated Okta Statement on Lapsus$ - https://news.ycombinator.com/item?id=30774193 - March 2022 (24 comments)

Also:

DEV-0537 (LAPSUS$) Criminal actor targeting organizations - https://news.ycombinator.com/item?id=30774406 - March 2022 (0 comments)

Lapsus$ hackers leak 37GB of Microsoft's alleged source code - https://news.ycombinator.com/item?id=30763623 - March 2022 (117 comments)

Re: Updated Okta Statement on Lapsus$

#234

Post by Closi »

haswell wrote: post #208
Closi wrote: post #182

Earlier quoted context omitted.

How it happened doesn't change the fact that they have been breached. If I was a bank and claimed that I haven't been robbed, an insider just transferred billions of pounds out of the bank and then fled, I think everyone would rightly say "What are you talking about, you have been robbed!" It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a…

> It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a bank robbery is a bank robbery. I have to respectfully disagree. Yes, the end result may be the same, but even in a bank robbery, the how matters, and will drive different behaviors from everyone involved: the bank, law enforcement, and customers of that bank. If as a customer, I learn t…

To be honest I think we are agreeing but arguing slightly different points.

The how matters, I agree, but it doesn’t change the fact that a breach is a breach.

Different breaches can have different severities, but they are still both breaches.

My issue isn’t on the severity of the breach, it’s that Okta are saying there wasn’t a breach.

Re: Updated Okta Statement on Lapsus$

#235

Post by d3nj4l »

lIIIllllIIII wrote: post #210
djrogers wrote: post #184

Earlier quoted context omitted.

You can take my laptop from me and have access to it without having compromised my Okta account. In that scenario you wouldn't have my okra password or my MFA - what you would have is transient access to everything I'd already auth'd to until it times out and requests that you auth again.

At which point your browser probably auto-fills the credentials again :-)

But ideally you would have MFA on a second device, so just the credentials aren't enough.

Re: Updated Okta Statement on Lapsus$

#236

Post by haswell »

Closi wrote: post #234
haswell wrote: post #208

Earlier quoted context omitted.

> It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a bank robbery is a bank robbery. I have to respectfully disagree. Yes, the end result may be the same, but even in a bank robbery, the how matters, and will drive different behaviors from everyone involved: the bank, law enforcement, and customers of that bank. If as a customer, I learn t…

To be honest I think we are agreeing but arguing slightly different points. The how matters, I agree, but it doesn’t change the fact that a breach is a breach. Different breaches can have different severities, but they are still both breaches. My issue isn’t on the severity of the breach, it’s that Okta are saying there wasn’t a breach.

Yeah, I think we're on the same page. The primary focus of my original reply was that the "how" really does matter. I agree that this is still a breach regardless.

Re: Updated Okta Statement on Lapsus$

#237

Post by vault »

hdlothia wrote: post #108
vault wrote: post #17

Earlier quoted context omitted.

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.

what does dolphined mean. is this a cyber security term?

https://www.urbandictionary.com/define.php?term=Dolphining

Re: Updated Okta Statement on Lapsus$

#238

Post by tatersolid »

londons_explore wrote: post #167
cheeze wrote: post #30

Earlier quoted context omitted.

I gotta say, I don't make technical decisions at the "we're using CF" level, but I've been incredibly impressed with their track record over the years. I often evangelize blog post writing and transparency at my company and this is exactly why. What a way to build trust. It's basically free advertising for technical folk by "putting their money where their mouth is." I'd love to see more of this in the industry. CF i…

Their blog posts are great, but for a service where reliability really really matters, they've had a few too many global outages. Especially considering their core proxying service doesn't have any requirement for a globally consistent datastore, there is zero excuse for a global outage.

> doesn't have any requirement for a globally consistent datastore

How do you think they manage configuration for proxying millions of customer websites? Using a globally distributed data store.

Re: Updated Okta Statement on Lapsus$

#239

Post by rampole »

Consultant32452 wrote: post #61
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.

Do you have a reference for this? Thanks.
Post reply on HN