I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. 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." and the screenshots of the attackers looking at Okta's support portal.
How is that lots more details ? Your post is only about whether or not CF Okta account has been compromised not about what really happened for all Okta customers
I thought that a CF person (can’t remember if it was Prince or not) said in the main HN thread yesterday, that CF uses their own homegrown SSO internally, and Okta externally, but this blog article seems to infer the opposite…
Anyway, I likely misinterpreted yesterday’s comment..
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 is, IMO, industry leading here.
> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords.
Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit.
What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned as what couldn't be obtained and not the tokens from MFA as well, does that mean they could obtain those tokens?
I wonder how it fits in with the groups own statements that they still have active access. Gonna be interesting to see what Lapsus$ replies to this statement.
> 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.
I wouldn't have realized that unless I'd read far enough to see that Entity A did compromise Account B. Since the author didn't define what an attempt in this context means, I think it would be proper to assume that attempt meant the overall effort to compromise the account.
Don't believe for a moment that this misdirection is unintentional. It's one big reason you might have contract workers instead of employees in this role, actually.
IMHO it's more of an empty statement. They never pin down what end-state is being discussed. So we can't evaluate if "additional steps are needed" to achieve that (unspecified) state.
It could be that the speaker is intentionally equivocating. I.e., knowing that the audience will assume some particular end-state. But if cornered, the speaker can claim (lie) that he implicitly meant a different end state.
>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 gives future attackers --hat colour dismissed-- an immediate incentive to simply publish regardless as you dont appear to be acting with very much good faith. if this sort of an attack is a carrot, you've clearly shown a predilection for the stick.
If there is one thing you want from a 3rd party auth provider, it's trust - this is not the time to play word games.
I'd have far more faith in them if they were transparent about what had happened, what they're doing about it, and how they will make sure it can't happen again.
Instead, they are being weasels - I for one, will not be using their services again, and this behaviour is the reason why.
Here's another example from a couple of years back where they used some really weasely language to claim they weren't vulnerable to a CVE (spoiler: they were):
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.
> 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.
> 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.
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.
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 saw the tweet a few mins after it was posted (thanks to the original article here on HN). We are a small startup and made the call to treat this like an exercise in failover process and ripped Okta out from our systems in around an hour. It was satisfying to see the process work. Original emails to staff were to wait for Okta to weigh in with their response before moving back to SSO but… not sure how that’s looking now given how they’re handling things so far.
There were a lot of doomsday predictions in yesterday's thread before any real info had been shared, but it was always the more likely scenario that a support agent contracted through a vendor would have limited read access to their internal systems and wouldn't be able to cause any real damage.
> 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.
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.
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.
[+] [-] templapsusread|4 years ago|reply
[+] [-] mimikatz|4 years ago|reply
[+] [-] jgrahamc|4 years ago|reply
[+] [-] polote|4 years ago|reply
[+] [-] ktsayed|4 years ago|reply
[+] [-] indigodaddy|4 years ago|reply
Anyway, I likely misinterpreted yesterday’s comment..
[+] [-] cheeze|4 years ago|reply
I'd love to see more of this in the industry. CF is, IMO, industry leading here.
[+] [-] Fabricio20|4 years ago|reply
As far as I can see, there's a lot of cloudflare accounts visible in the screenshots shared by the group. Stuff like cloudflaretv1, etc..
[+] [-] chockchocschoir|4 years ago|reply
Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit.
What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned as what couldn't be obtained and not the tokens from MFA as well, does that mean they could obtain those tokens?
I wonder how it fits in with the groups own statements that they still have active access. Gonna be interesting to see what Lapsus$ replies to this statement.
[+] [-] smcl|4 years ago|reply
It looked kinda successful though...
[+] [-] duncan-donuts|4 years ago|reply
Yeah, it was.
[+] [-] benatkin|4 years ago|reply
I wouldn't have realized that unless I'd read far enough to see that Entity A did compromise Account B. Since the author didn't define what an attempt in this context means, I think it would be proper to assume that attempt meant the overall effort to compromise the account.
[+] [-] Helloyello|4 years ago|reply
[deleted]
[+] [-] dboreham|4 years ago|reply
"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".
[+] [-] hackmiester|4 years ago|reply
[+] [-] HL33tibCe7|4 years ago|reply
Oh okay then, pack up guys, everything’s fine
I really hate this kind of corporate bullshit
> There are no corrective actions that need to be taken by our customers.
Isn’t this an objectively false statement?
[+] [-] CoastalCoder|4 years ago|reply
IMHO it's more of an empty statement. They never pin down what end-state is being discussed. So we can't evaluate if "additional steps are needed" to achieve that (unspecified) state.
It could be that the speaker is intentionally equivocating. I.e., knowing that the audience will assume some particular end-state. But if cornered, the speaker can claim (lie) that he implicitly meant a different end state.
[+] [-] nimbius|4 years ago|reply
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 gives future attackers --hat colour dismissed-- an immediate incentive to simply publish regardless as you dont appear to be acting with very much good faith. if this sort of an attack is a carrot, you've clearly shown a predilection for the stick.
[+] [-] GordonS|4 years ago|reply
I'd have far more faith in them if they were transparent about what had happened, what they're doing about it, and how they will make sure it can't happen again.
Instead, they are being weasels - I for one, will not be using their services again, and this behaviour is the reason why.
Here's another example from a couple of years back where they used some really weasely language to claim they weren't vulnerable to a CVE (spoiler: they were):
https://twitter.com/jonoberheide/status/1506280347306188805?...
[+] [-] different_sort|4 years ago|reply
Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.
[+] [-] dzhiurgis|4 years ago|reply
We should not glorify them.
[+] [-] hughrr|4 years ago|reply
[+] [-] Melatonic|4 years ago|reply
[+] [-] Bombthecat|4 years ago|reply
[+] [-] gurjeet|4 years ago|reply
[deleted]
[+] [-] koolba|4 years ago|reply
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.
[+] [-] bhaney|4 years ago|reply
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.
[+] [-] giaour|4 years ago|reply
[+] [-] Consultant32452|4 years ago|reply
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.
[+] [-] paxys|4 years ago|reply
[+] [-] mdoms|4 years ago|reply
[+] [-] dogecoinbase|4 years ago|reply
[+] [-] Melatonic|4 years ago|reply
[+] [-] sergiotapia|4 years ago|reply
The rest of the note literally show they have been breached. What?
[+] [-] uean|4 years ago|reply
[+] [-] hericium|4 years ago|reply
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.
[+] [-] paxys|4 years ago|reply
[+] [-] dang|4 years ago|reply
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)
[+] [-] eyeareque|4 years ago|reply
[+] [-] mdoms|4 years ago|reply
There it is.
[+] [-] ppvfy|4 years ago|reply
> 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?
[+] [-] daenz|4 years ago|reply
[+] [-] gtsteve|4 years ago|reply
[0] https://www.csoonline.com/article/3389138/how-onelogin-respo... (unsurprisingly the canonical article from their weblog is missing now)
[+] [-] skilled|4 years ago|reply
[+] [-] Johnny555|4 years ago|reply