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

161–170 of 239 posts

Re: Updated Okta Statement on Lapsus$

#161

Post by gtsteve »

daenz wrote: post #129

Given the nature of what Okta does, is this going to kill them? It's like the business version of a headshot.

Probably not. It's really inconvenient for a large organisation to drop them given how embedded identity gets into everything. It's reputational damage but something worse [0] happened to OneLogin a few years back and they're still around.

[0] https://www.csoonline.com/article/3389138/how-onelogin-respo... (unsurprisingly the canonical article from their weblog is missing now)

Re: Updated Okta Statement on Lapsus$

#162

Post by dzhiurgis »

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.

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

Re: Updated Okta Statement on Lapsus$

#163

Post by adam0c »

Copy / Paste from Lapsuss telegram ;)

https://www.okta.com/blog/2022/03/updated-okta-statement-on-...

I do enjoy the lies given by Okta.

1. We didn't compromise any laptop? It was a thin client.

2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the ability to reset the Password and MFA of ~95% of clients isn't successful?

4. For a company that supports Zero-Trust. Support Engineers seem to have excessive access to Slack? 8.6k channels? (You may want to search AKIA* on your Slack, rather a bad security practice to store AWS keys in Slack channels )

5. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. - Uhm? I hope no-one can read passwords? not just support engineers, LOL. - are you implying passwords are stored in plaintext?

6. You claim a laptop was compromised? In that case what suspicious IP addresses do you have available to report?

7. The potential impact to Okta customers is NOT limited, I'm pretty certain resetting passwords and MFA would result in complete compromise of many clients systems.

8. If you are committed to transparency how about you hire a firm such as Mandiant and PUBLISH their report? I'm sure it would be very different to your report :)

_________________________________________________________________________________________________________________________________________________________________________________________________________ https://www.okta.com/sites/default/files/2021-12/okta-securi...

21. Security Breach Management. a) Notification: In the event of a Security Breach, Okta notifies impacted customers of such Security Breach. Okta cooperates with an impacted customer’s reasonable request for information regarding such Security Breach, and Okta provides regular updates on any such Security Breach and the investigative action and corrective action(s) taken. -

But customers only found out today? Why wait this long?

9. Access Controls. Okta has in place policies, procedures, and logical controls that are designed:

b. Controls to ensure that all Okta personnel who are granted access to any Customer Data are based on leastprivilege principles;

kkkkkkkkkkkkkkk

1. Security Standards. Okta’s ISMP includes adherence 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$

#164

Post by gkop »

horsawlarway wrote: post #150
gkop wrote: post #118

Earlier quoted context omitted.

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

There are cases where this is impossible. Ex - You have gmail gated behind okta using MFA, and the lost device is the user's MFA (ex - phone using TOTP). If the user has no session currently logged in on another device, they won't be able to create a session without their MFA device, and therefore won't be able to access their email. How likely you are to hit this depends on org settings, like gmail session time, okt…

As an enterprise customer, in the scenario you provided, I’d prefer if the vendor makes this my problem, by forcing me to reset the individual user’s MFA configuration, rather than try to be helpful in such a way that requires support personnel have the ability to do so.

(And if I lock myself out, make it very very expensive for me to prove my identity to recover access)

Re: Updated Okta Statement on Lapsus$

#165

Post by dvtrn »

hughrr wrote: post #142
maldeh wrote: post #119

Earlier quoted context omitted.

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 2701…

Yep. All these standards are tick boxing for liability. Nothing more. They are not effective security controls and never will be and should never be a measure of that.

We’ve been monitoring this internally, as customers of an Okta-like service.

I’ve also been closely monitoring the responses from our CTO and VP of Security when someone from our DevOps team posted a link to the Verge article in slack this morning.

Which brings me to this inquiry: How are your orgs responding to this? We have a dependency on an Okta-like provider and my first thought when reading this news was “you know, wonder if we should give our shit a sanity check”, and someone beat me to this, proposed it in slack but the idea was turned down by our SecOps team.

Re: Updated Okta Statement on Lapsus$

#166

Post by 0xbadcafebee »

lambda_dn wrote: post #132

My booking.com account was hacked and someone from China booked a hotel using my account (Im in UK). Managed to cancel it for free, changed password, logged out of all sessions, turned on 2FA and removed all cards. Wondering if this is related.

My booking.com account also notified me someone booked a hotel in Brazil, and I went in and cancelled it and reported it. Extra weird because the notification came in through an old email address. That was on Saturday, Mar 19, 10:43 PM EDT. But it could have just been a large attack on Booking.com, unknown if it's Okta-related (and not necessarily a compromise, if I accidentally reused a password)

Re: Updated Okta Statement on Lapsus$

#167

Post by londons_explore »

cheeze wrote: post #30
jgrahamc wrote: post #2

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

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.

Re: Updated Okta Statement on Lapsus$

#168

Post by hcazz »

trhway wrote: post #90

Looks like Lapsus didn't do any damage and thus Okta dismisses the breach as not a breach - just like a proof-of-breach starting notepad.exe on compromised machine was at one of my old jobs dismissed because notepad doesn't do any damage. The security professionals today are the second sellers of snake oil after MBAs. Cue SolarWind with their it is ok for binaries' signatures to differ as they get deformed while bein…

>The security professionals today are the second sellers of snake oil

If someone breaks into your house, and stays there for a week, would you say they didn't really break in because they didn't murder you?

>proof-of-breach

Maybe you're referring to a "proof of concept"? A "proof of breach" in the security industry is an incident to be investigated, and if necessary, involve law enforcement. It isn't meddling kids that didn't cause any harm. As a side note, I've never heard anyone use the term "proof of breach" in that context in the industry.

The fact that Okta didn't detect this earlier is concerning in its own right, let's not downplay the fact that the level of access that third party providers have is not a solved issue in the industry. The RCA/post mortem/follow up actions from Okta's side should not be "they got access but didn't do anything with it, we don't need to change anything".

Re: Updated Okta Statement on Lapsus$

#170

Post by hughrr »

dvtrn wrote: post #165
hughrr wrote: post #142

Earlier quoted context omitted.

Yep. All these standards are tick boxing for liability. Nothing more. They are not effective security controls and never will be and should never be a measure of that.

We’ve been monitoring this internally, as customers of an Okta-like service. I’ve also been closely monitoring the responses from our CTO and VP of Security when someone from our DevOps team posted a link to the Verge article in slack this morning. Which brings me to this inquiry: How are your orgs responding to this? We have a dependency on an Okta-like provider and my first thought when reading this news was “you k…

Sounds about right. Here there will be a staff security training symposium that runs everyone through a training course bought in from the lowest bidder that is tangentially related to the issue followed by a self-congratulatory management meeting and that will be the whole issue resolved to satisfaction.
Post reply on HN