New update, but posted on top of the old public post. Now indicates Okta recognizes a breach officially and has started notified affected organizations.
I can't believe these idiots tried playing chicken with a hacker, heads need to roll over this one. They have completely and needlessly destroyed their credibility by trying and completely failing to control the narrative.
The comedy of this is that one would expect an authentication and identity platform to be in the top percent of good actors in security incident response.
Might be time to reinstall Active Directory in your basement.
AD controllers are a pain to maintain in the future though. At a BigCo I was SRE at, there were some running on ancient versions of Windows. The funny thing to me is, nobody was quite certain what exactly it gave access to. The support team would need to reset passwords for users on a weekly basis though. It was a huge mess.
AD is still shockingly robust. For one thing, if you were using "ancient versions of Windows", your experience was different than today. Though FWIW, it's a personal frustration that built-in features of Windows Server have been left to rot on the vine a bit because a lot of the resources Microsoft had working on them got shifted to Azure, because the cloud is a cash printer. There are a lot of modern UI conveniences that on-prem AD doesn't have for no reason other than Microsoft would rather you move to the cloud and pay them monthly per head.
I suspect that if your title was SRE, and they still had some on-prem AD controllers, they were probably not maintained as well as a place who still calls their IT folks SysAdmins, if the titles are any hint on the general focus of tech stacks.
I think the flip flopping is hurting them and their users more and more. What was initially a flat denial this morning has resulted in taunts from Lapsus$ on Twitter, Okta was out-scooped by Cloudflare's public investigation. Now they admit a breach affecting 2.5% (roughly 250 orgs based on public data).
The webinar tomorrow should be fascinating if they allow questions.
They've lost all credibility at this point. You can't say "we didn't get breached, nobody got owned" and then turn around and say "actually a lot of our customers did get owned" after you get called out on it.
They lost all credibility when they failed to do the one single thing companies trust them to do, on a massive and severe scale, with long-lasting financial repercussions for AT LEAST 250 of the worlds biggest companies (I believe it's more than they're letting on).
It is a shame that the new DHS 72 hour reporting requirement was not in effect when this breach occurred, but it is extremely evident why it is required. Regarding business classification, I don't think it's too difficult to argue that commercial identity providers are critical infra.
That law is modelled on laws in the EU, Australia and other countries. I know if my employer is one of the affected companies they are in breach of our notification laws.
GDPR already covers this. If companies with EU employees were among the 2.5% ( not unlikely), they should have disclosed this, first to the ICO and customers, then the public.
It's kinda funny and also very very sad that with javascript disabled, the website loads for a split second and then is covered by a fullscreen "Looks like you have Javascript turned off! Please enable it to improve your browsing experience." javascript blocker blocker, but if you delete the element, the page appears to work perfectly fine. It really is the ultimate in "fuck your browsing experience, our marketing spam scripts are the most important thing".
Do I believe the revision? Well, I believe it more than the flat denial, but I doubt the scale. I expect another revision because Okta showed they revise in the light of emerging evidence and experience.
The fact that they didn’t disclose the original breach when they detected it should be cause for any company serious about security to reject Okta as a potential vendor.
Hopefully this Webinar isn't a way to hide the details from anyone who isn't a customer, or hopefully someone in the webinar catalogues all information shared.
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 :)
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?
This appears to confirm that LAPSUS$ may have limited to the following access:
- Getting access to a list of accounts (and by extension any new accounts) of an organisation. This would perhaps allow an attacker to beat a new employee through the enrollment process if the attacker were to find out that all new employees get their temporary password set as P@S$w0rd until they enroll for the first time and are required to set a real password. Alternatively, social engineering attacks would be made easier to attempt contact with new employees directly to "help" them with onboarding ("Employee: Why does my MFA token keep resetting? Attacker: You didn't know that you have to first register it at company.oktamfa.com/register?").
- Resetting MFA for a user so that the attacker could then login to an organisation's user account they already know the password for (from other sources assuming password reuse), re-enrolling MFA in the process and therefore effectively bypassing MFA.
- Sending a reset password link via e-mail to a user. The user would be able to continue logging in with their credentials so it does not appear this would cause a denial of service opportunity [1] [2]. For more sophisticated attackers (states) perhaps this is also an opportunity to capture the cleartext reset URL token to gain access to the account if the attacker has access tot he network path the e-mail is sent over.
- Resetting a user password to a temporary one that is e-mailed to the user in plaintext. Would create an annoyance to users in that their current credentials would stop working all of a sudden and they'd have to check their e-mail for the temporary password to use and reset their account [1] [2]. Despite [2] indicating that temporary passwords can be viewed by an administrator of an organisation setting a temporary password, the statement at [3] indicates Okta staff are not able to view the temporary passwords generated and can only send them via e-mail to the user. This is a potential temporary denial of service (lower impact) or for more sophisticated attackers (states) perhaps an opportunity to capture the cleartext password via e-mail if they have access to the network path the e-mail is sent over.
- Getting and elevating access to other internal systems via information mistakenly published for internal Okta employees in Jira or Slack.
- Being able to find and exploit a vulnerability in the administration/superuser systems, Jira, Slack or other internal systems used by Okta to gain greater access.
If LAPSUS$ had already gained some of these higher levels of access, it appears they would have already revealed it.
There are thousands of organizations spending a lot of money on okta that are demanding answers. If they didn't respond, their business wouldn't survive.
I hope their business does not survive; it’s a terrible company with bad products. But I don’t see them going anywhere. They’ve won over IT administrators, many of whom are all in with Okta (and the no code movement). Hard to see them giving up all that investment.
This seems to be common, given disclosures that other companies have been doing the same thing. Since Slack is not end-to-end encrypted, imagine if Slack was compromised. The amount of credentials an attacker could have access to by just doing some searches would be quite devastating to a lot of companies.
