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

111–120 of 239 posts

Re: Updated Okta Statement on Lapsus$

#111

Post by Ozzie_osman »

Eyas wrote: post #103
ckozlowski wrote: post #91

Earlier quoted context omitted.

Without proper separation of duties to limit blast radius, it's just as damaging as a software vulnerability. It sounds like that's the real issue here: Compromise of a support engineer lead to far more access than should have been permissible.

Right, but their claim is that there were proper separations that successfully did limit the blast radius.

Or at the very least, audit logs so they can see what that support engineer's account did during the period that the account was compromised.

Re: Updated Okta Statement on Lapsus$

#112

Post by ppvfy »

> The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers.

> Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords.

Those two things are at odds with each other, no?

Re: Updated Okta Statement on Lapsus$

#113

Post by kichik »

ev1 wrote: post #104
different_sort wrote: post #83

Earlier quoted context omitted.

Maybe I’m just an unimpressed security professional but I’ve still not seen evidence I’d call a breach. At least not a significant one if you want to argue sublantics. Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.

I do security (albeit not CISO or compliance-style, but commercial anticheat), and in my opinion, if a support agent's account was used by a third party to view anything about my account without permission - any undisclosed email address or name, their system was compromised and it is a data breach. IMO, support agents also should not have the ability to view or access a customer's account without some form of time l…

Yeah, the screenshots they admit are real clearly show Slack, JIRA and AWS being open. What did the attackers see there? Were the customers whose data was viewed notified? How can Okta tell if that data is sensitive or not without taking to their customers?

Re: Updated Okta Statement on Lapsus$

#114

Post by viraptor »

politelemon wrote: post #79
templapsusread wrote: post #31

Earlier quoted context omitted.

they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...

8600 channels? Wouldn't that overwhelm you? I'm trying to think up scenarios where an org would need so many, but I can't. Is this normal?

You're not going to be even aware of the majority of the channels. In my experience having ~1.5 channels per employee sounds right across the company. I've started channels for: specific incidents, personal huddle, lunchtime game organisation, limited notifications target, etc. Also we don't know if they count archived channels or not.

Re: Updated Okta Statement on Lapsus$

#115

Post by mardifoufs »

different_sort wrote: post #83
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…

Maybe I’m just an unimpressed security professional but I’ve still not seen evidence I’d call a breach. At least not a significant one if you want to argue sublantics. Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.

If you follow the lapsus telegram, you will see they are claiming they got AWS API keys from the corporate slack. That might be more dangerous than accessing the support console

Re: Updated Okta Statement on Lapsus$

#116

Post by dboreham »

The post could use some review/edit. This:

"a customer support engineer working for a third-party provider"

actually means

"one of our customer support engineers, who happens to be an employee of another company, working for us under contract".

Re: Updated Okta Statement on Lapsus$

#117

Post by tuwtuwtuwtuw »

hericium wrote: post #13

> limited data - for example, Jira tickets I wonder how many passwords and other creds were harvested from tickets alone. Lapsus$ went after Okta's customers and in some cases successfully, it appears.

> it appears.

Where does it appear like that? I have tried to follow this but the only thing I have seen shares is info from within Okta. I have seen email addresses of CloudFlare employee in screenshot of Okta, is that what you are referring to?

Re: Updated Okta Statement on Lapsus$

#118

Post by gkop »

lalopalota wrote: post #45
chockchocschoir wrote: post #37

Earlier quoted context omitted.

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.

In this scenario, it’s more secure to require the user to request their own password reset via their registered email address.

Re: Updated Okta Statement on Lapsus$

#119

Post by maldeh »

templapsusread wrote: post #31
templapsusread wrote: post #23

Lapsus has responded https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c...

they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...

A more poignant elegy to the modern landscape of compliance theater I have never seen:

> Security Standards. Okta's ISMP includes adherance to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes:

> a) Internal risk assessments;

> b) ISO 27001, 27002, 27017 and 27018 certifications;

> c) NIST guidance; and

> d) SOC2 Type II (or successor standard) audits annually performed by accredited third-party auditors ("Audit Report").

I don't think storing AWS keys within Slack would comply to any of these standards?

Re: Updated Okta Statement on Lapsus$

#120

Post by zerkten »

intunderflow wrote: post #51
templapsusread wrote: post #31

Earlier quoted context omitted.

they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...

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?

Frequently, support teams have lab environments. Hopefully, it'd be an account per engineer, but at least isolated from production. If software engineers access these for reviewing issues which made their ways to bugs, then potentially this is a vector that organizations should be concerned about. Attackers will be happy to make 20+ pivots, so even an isolated AWS account for a support engineer is a nice base.
Post reply on HN