We have determined that the threat actor ran and downloaded a report that contained the names and email addresses of all Okta customer support system users. All Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor). The Auth0/CIC support case management system was also not impacted by this incident.
The threat actor ran a report on September 28, 2023 at 15:06 UTC that contained the following fields for each user in Okta’s customer support system:
Created Date
Last Login
Full Name
Username
Email
Company Name
User Type
Address
[Date of] Last Password Change or Reset
Role: Name
Role: Description
Phone
Mobile
Time Zone
SAML Federation ID
The majority of the fields in the report are blank and the report does not include user credentials or sensitive personal data. For 99.6% of users in the report, the only contact information recorded is full name and email address.
Okta has around 18,000 customers according to the company’s website. So that’s a major problem for Okta. And an equally major problem for any Okta customer. And the fact that there’s no credentials in this report that the threat actors ran is irrelevant. A threat actor could still use this information to launch phishing attacks against any Okta customer to pwn them. Even if only 1% of those customers get pwned via a phishing attack or some other attack, it’s 1% too many.
Now to be fair, Okta does suggest the following mitigations be implemented ASAP:
We recommend all customers immediately take the following actions to defend against potential attacks that target their Okta administrators.
Multi-Factor Authentication (MFA): We strongly recommend all Okta customers secure admin access using MFA at a minimum. We also strongly encourage customers to enroll administrative users in phishing resistant authenticators (such as Okta Verify FastPass, FIDO2 WebAuthn, or PIV/CAC Smart Cards) and to enforce phishing resistance for access to all administrative applications. Please refer to product documentation to enable MFA for the admin console (Classic or OIE).
Admin Session Binding: As communicated in the Security Incident RCA, customers can now enable an Early Access feature in Okta that requires admins to reauthenticate if their session is reused from an IP address with a different ASN (Autonomous System Number). Okta strongly recommends customers enable this feature to further secure admin sessions.
Admin Session Timeout: To align with NIST AAL3 guidelines and increase the security posture of every customer, Okta is introducing Admin Console timeouts that will be set to a default of 12-hour session duration and a 15-minute idle time. Customers will have the option to edit these settings. This will be available as an Early Access feature starting November 29th for preview orgs and December 4th for production orgs. The feature will be available for all production orgs by January 8th, 2024. An email was sent to all Super Admins regarding this change on November 27th, and a copy of that communication can be found in the Knowledge Base article: Admin Session Lifetime/Idle Timeout Security Enhancements.
Phishing Awareness: In addition, Okta customers should be vigilant of phishing attempts that target their employees and especially wary of social engineering attempts that target their IT Help Desks and related service providers. We recommend Okta customers implement our industry-leading, phishing-resistant methods for enrollment, authentication, and recovery. Please see Okta Solutions for Phishing Resistance for more information on protecting your organization from phishing. We also strongly recommend that customers review their IT Help Desk verification processes and ensure that appropriate checks, such as visual verification, are performed before performing high risk actions such as password or factor resets on privileged accounts.
While all of this is good advice, it doesn’t change the fact that this event really reflects poorly on Okta and I am not sure how any Okta customer could ever trust the company again. Which means that Okta really has to explain why customers should trust them going forward. And they need to do it fast.
This entry was posted on November 29, 2023 at 10:30 am and is filed under Commentary with tags Okta. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Remember The Okta Hack Where They Explained It Only Impacted 1% Of Customers? It Was Actually 100% Of Customers.
Okta has released a new statement in relation to that hack that they had a while ago. At the time, they said it only affected 1% of customers. Well, that statement that I referred to one sentence ago says something different:
We have determined that the threat actor ran and downloaded a report that contained the names and email addresses of all Okta customer support system users. All Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor). The Auth0/CIC support case management system was also not impacted by this incident.
The threat actor ran a report on September 28, 2023 at 15:06 UTC that contained the following fields for each user in Okta’s customer support system:
The majority of the fields in the report are blank and the report does not include user credentials or sensitive personal data. For 99.6% of users in the report, the only contact information recorded is full name and email address.
Okta has around 18,000 customers according to the company’s website. So that’s a major problem for Okta. And an equally major problem for any Okta customer. And the fact that there’s no credentials in this report that the threat actors ran is irrelevant. A threat actor could still use this information to launch phishing attacks against any Okta customer to pwn them. Even if only 1% of those customers get pwned via a phishing attack or some other attack, it’s 1% too many.
Now to be fair, Okta does suggest the following mitigations be implemented ASAP:
We recommend all customers immediately take the following actions to defend against potential attacks that target their Okta administrators.
While all of this is good advice, it doesn’t change the fact that this event really reflects poorly on Okta and I am not sure how any Okta customer could ever trust the company again. Which means that Okta really has to explain why customers should trust them going forward. And they need to do it fast.
Share this:
Like this:
Related
This entry was posted on November 29, 2023 at 10:30 am and is filed under Commentary with tags Okta. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.