Okta: “We made a mistake” delaying the Lapsus$ hack disclosure
bleepingcomputer.com
bleepingcomputer.com
* a third party has barely restricted, deep access to all customer data
* the "SuperUser" app can apparently have logged in users idling around in a VM, waiting for someone to come along and use it without any automatic logout and re-authentication
* a single account accessing 300+ customers in a few days doesn't trigger any alerts
* they detect a compromise, and do absolutely nothing about it for months, except letting the third party order a security audit; they patiently wait for a report; they don't even audit the access logs
* only a screenshot posted online triggers an audit of access logs and a public response
* they still try to blame the third party and the security firm for their own (basically outrageous) inactivity
All of this by a company entrusted with the most critical gatekeeping functionality of systems, used by many large enterprises and expected to have top notch security.
An MS environment is today extraordinary complex and it is very easy to make a mistake setting it up, maintaining and integrating other stuff with it.
The issue here is that 1) an employee was able to be phished and/or have malware installed on their device and 2) support agents should only have access to accounts where they have been assigned a ticket, and agents should have no control over which tickets they get assigned.
In these cases, the support agents should not have the ability to open support tickets or modify the companies on them - and then you can give them superuser access to companies with currently open support tickets (preferably those they are assigned only).
"All" is not correct, they outlined what data was in the Superuser utility. It certainly has access, but not "all" data.
> the "SuperUser" app can apparently have logged in users idling around in a VM, waiting for someone to come along and use it without any automatic logout and re-authentication
Well it was an employee laptop, not a VM (so the news says). But regardless of this, the question is what is the session length of superuser? It could be 20mn, it could be 1hr, it could be 8hr. There is some balance for security and usability of the team who actually uses that tool. Even if the session length is reasonably short, this was an insider willingly giving up access to their machine. So likely the insider logged in and sent the attackers a message saying "here you go" and let them work for as long as the session would last. Heck, the insider may even repeatedly login for them.
> a single account accessing 300+ customers in a few days doesn't trigger any alerts
Almost every support interaction would likely require the access of that customer in the superuser utility. Just a dozen cases an hour for an 8 hour day, is nearly 100 accounts accessed per day. That doesn't even seem like a lot of cases per hour.
I'm not saying Okta is in the right here. But throwing around a lot of FUD doesn't help the situation.
And even now, they are not coming out and being honest like "we lied because we were scared about liability, but the person behethis decision has been fired". It's not good enough.
Sorry, but they have some serious work to do if they want to regain that trust. I for one, will not be using their services again.
The only rational reason I can come up with for this duplicitous talk is for the shareholders; with this double speak they can reduce just how much their shares fall. I'm not on a high horse, I'm positive that most of our orgs was do the same thing.
And I'm not surprised that they're just like all other large companies that choose money/PR over accuracy. What is maddening is that they made it so hard to zero in on required information to help us assess risk; they're at the center of a lot of security workflows, and accurate information is more critical from them than it is from others.
I fear for Auth0 and what it ~~may~~ will become under Okta's 'culture'.
Whenever you hear "Public Relations" just replace it with "Propaganda" since that is what is always was.
https://blog.apaonline.org/2020/07/06/recently-published-boo...
"How Propaganda Became Public Relations: Foucault and the Corporate Government of the Public is a philosophical investigation into the transformative effect propaganda has on us as individuals, on us as publics, and on society more broadly. I argue that propaganda does far worse than just lie to us: modern propaganda aims to transform us into the kind of subjects who carry out a particular line of conduct freely and as a key part of our identity. "
Every company engages in propaganda. The fact that you believe Okta from the start was because of their propaganda.
From talking to other users, Cognito is okay as long as you don't need any real customization. It's also great if you need to get AWS credentials on login. But there are plenty of folks who start with Cognito, run into its limitations, and move elsewhere (even if they stay with AWS for other service). Here's a story about someone who moved from Cognito to FusionAuth: https://fusionauth.io/blog/2020/11/18/reconinfosec-fusionaut...
I am a very unhappy customer who is very interested in Keycloak.
Honestly, most of these companies would be better off using Google, Azure or AWS' SSO-as-a-Service product (if that's what you're hoping to get out of Keycloak).
That's not to say that I don't appreciate that there's an open-source alternative out there, however.
Interesting enough is it looks like it will be provider agnostic.
You could use the “raw” saml endpoint provided by the service, a Google Identity endpoint, Okta provided saml endpoint, shibboleth on-prep protected by Tunnels, jumpcloud etc.
There’s even an saml/SSO preview of what data will be sent to the application upon authZ by the Identity Provider. There’s configuration rules already in place (AuthN) that can be applied to Organizational Units based upon the user’s metadata.
It’s a pretty clear bet at this point that Cloudflare will be making an entrance. Considering they used Okta internally performing a rapid investigation of the breach, (1) is the right thing to do as a service provider/rails to the internet (2) is strong product marketing for their future product (3) can be used to gain internal support for replacing Okta with their own product
The thing is, your Keycloak instance is not going to matter to any hacker, particularly if it's inside a VPN and not reachable from the Internet - and while we're at it, fuck zero-trust because it is essentially the same level of stupidity as using Okta, you're once again putting all your eggs into the basket of whatever provider you choose.
Your SSO-as-a-service provider however? They're the juiciest target out there that is. Everyone from secret services over enemy nation states to your average cyber-criminal is looking to get access there. And as we've seen, all it takes is a couple teenagers and a couple thousand dollars.
Good network design costs a lot of money to set up, particularly to limit the scope of an attack (e.g. because the VPN software had a vulnerability), but it's orders of magnitude better in the long run than to outsource core IT to some incompetent fools with subcontractors.
This doesn't make it particularly usable as SSO...
>Good network design costs a lot of money to set up, particularly to limit the scope of an attack (e.g. because the VPN software had a vulnerability), but it's orders of magnitude better in the long run than to outsource core IT to some incompetent fools with subcontractors.
This is exactly my point. Most businesses not not have the resources to maintain this level of infrastructure.
Additionally, I'm personally of the opinion that walled gardens with VPN entry points are a particularly good choice for modern businesses these days. Even the White House OMB is pushing the beyondcorp model in their recent recommendations for ZT.
Why? Your core IT should not be visible from outside a VPN anyway, and if you're in a VPN you can use your Keycloak or whatever SAML system as you wish.
> Most businesses not not have the resources to maintain this level of infrastructure.
And right here is the problem: too many businesses see IT simply as a cost center instead of as what it is: a vital part of the business. You can't even run a grocery store without computers any more, and even a grocery store is a juicy target for criminals given that credit card data is processed there (not to mention employment records that can be used for identity impersonation).
People simply go and attach whatever bullshit devices from HVAC controllers to crappy 10$ IoT surveillance cameras fresh off of Alibaba on their core network and in some cases even "convenience wifi for customers", and then they wonder why either hackers or the feds come knocking. Jesus.
The problem with this approach is that, repeated by hundreds of companies at scale, paints such a massive target on the vendor, that a breach becomes fundamentally inevitable.
I expect this sort of thing happens to all big auth providers, from AWS to Google; it's just dealt with more efficiently and discreetly.
1. They didn’t try to downplay the leak
2. Didn’t double down on the leak not being a big deal later
3. Didn’t specialize in authentication and security
Cubicle farms, unprofessional managers constrained by ops managers who play favorites, and fiefdoms.
Why? There are only two positions at Sitel: On the phone, or off, and no one who has ever gotten off the phone wants to ever go back, so their relations between Ops and Team Managers are always strained.
In a word, at Sitel crap rolls down hill and collects there until it drowns you.
This whole thing is like an exercise in plausible deniability, corporate double-speak, blame shifting and arrogance.
You could even say, they had a lapse of judgment. Sorry for the pun.
That was plastered all over the HN and reddit threads a few days ago, no mention of it from Okta yet. Did that turn out to be bogus?
From the screenshot:
> I don't think storing AWS keys within Slack would comply to any of these standards?
> We're not actually writing one here but it'll make the examples easier if we pretend we are. Just for the sake of example, I'm going to pick on NVIDIA because... Why not? Such a driver is clearly missing and really should happen soon. (Hint! Hint!) We're going to call this hypothetical new Vulkan driver NVK. It's short and obvious.
As I said in another comment thread about this event, I’ve been watching my leadership team’s response to this as we have deep Okta integration, therefore so do several of our customers using our platform.
Said response has been pretty interesting and amounted to: “it’s working isn’t it?” when shown this event and the disclosures. Both executive and functional Security leadership teams practically shrugged.
Very glad I’m not the one making that call.