When KrebsOnSecurity broke the news on Oct. 20, 2023 that identity and authentication giant Okta had suffered a breach in its customer support department, Okta said the intrusion allowed hackers to steal sensitive data from fewer than one percent of its 18,000+ customers. But today, Okta revised that impact statement, saying the attackers also stole the name and email address for nearly all of its customer support users.
Okta acknowledged last month that for several weeks beginning in late September 2023, intruders had access to its customer support case management system. That access allowed the hackers to steal authentication tokens from some Okta customers, which the attackers could then use to make changes to customer accounts, such as adding or modifying authorized users.
In its initial incident reports about the breach, Okta said the hackers gained unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers, or less than 1% of Okta’s customer base.
But in an updated statement published early this morning, Okta said it determined the intruders also stole 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),” Okta’s advisory states. “The Auth0/CIC support case management system was also not impacted by this incident.”
Okta said that for nearly 97 percent of users, the only contact information exposed was full name and email address. That means about three percent of Okta customer support accounts had one or more of the following data fields exposed (in addition to email address and name): last login; username; phone number; SAML federation ID; company name; job role; user type; date of last password change or reset.
Okta notes that a large number of the exposed accounts belong to Okta administrators — IT people responsible for integrating Okta’s authentication technology inside customer environments — and that these individuals should be on guard for targeted phishing attacks.
“Many users of the customer support system are Okta administrators,” Okta pointed out. “It is critical that these users have multi-factor authentication (MFA) enrolled to protect not only the customer support system, but also to secure access to their Okta admin console(s).”
While it may seem completely bonkers that some companies allow their IT staff to operate company-wide authentication systems using an Okta administrator account that isn’t protected with MFA, Okta said fully six percent of its customers (more than 1,000) persist in this dangerous practice.
In a previous disclosure on Nov. 3, Okta blamed the intrusion on an employee who saved the credentials for a service account in Okta’s customer support infrastructure to their personal Google account, and said it was likely those credentials were stolen when the employee’s personal device using the same Google account was compromised.
Unlike standard user accounts, which are accessed by humans, service accounts are mostly reserved for automating machine-to-machine functions, such as performing data backups or antivirus scans every night at a particular time. For this reason, they can’t be locked down with multifactor authentication the way user accounts can.
Dan Goodin over at Ars Technica reckons this explains why MFA wasn’t set up on the compromised Okta service account. But as he rightly points out, if a transgression by a single employee breaches your network, you’re doing it wrong.
“Okta should have put access controls in place besides a simple password to limit who or what could log in to the service account,” Goodin wrote on Nov. 4. “One way of doing this is to put a limit or conditions on the IP addresses that can connect. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.”
Goodin suggested that people who want to delve further into various approaches for securing service accounts should read this thread on Mastodon.
“A fair number of the contributions come from security professionals with extensive experience working in sensitive cloud environments,” Goodin wrote.
Okta’s CEO’s post on LinkedIn was essentially…..yes, we know we have security issues but did you see our amazing 3rd quarter financial performance!
I’m concerned that Okta no longer gets what is important to their customers and won’t understand until after they’ve caused a critical security incident for all their customers.
>until after they’ve caused a critical security incident for all their customers.
…again? You mean, like how LAPSUS$ gained access to a super-administrator account, letting them reset the admin password to any organization they wanted, with no active monitoring going “hey what the fuck”?
” it should have been impossible for employees to be logged in to personal accounts on a work machine”
I’m assuming that the employee who saved work credentials to their personal Google account did so in a web browser. Is it possible for administrators to control to which Google accounts a user is able to connect their web browser?
David, yes this is possible. Most content filters should be able to accomplish this. I’ve done it in the past with Fortigate firewalls, but I would imagine that any major content filter would have the same functionality. I used the content filtering capabilities to only allow corporate Gmail accounts and block all personal.
Brian – has attribution been identified for this breach? I am not sure I would want to be an Okta customer right now …
Okta said it had seen this adversary before, but that’s as far as they would go, at least as far as I recall.
That’s an interesting Mastadon discussion.
Why would any company even have access to such accounts available on the Internet?
For our command and control software and for communications between servers, which predominately uses ssh, we have a separate LAN with no internet access and the associated accounts on the servers cannot be connected to from anything but that one very private network.
One thing that I have been playing with is creating several hundred accounts on each server with the idea of using them as a sentinel. Then if an attacker breaks in and looks to see what accounts are on there, he is likely to try to do something to explore those accounts to see if any of them are really valuable. Monitor those accounts tightly and you should know pretty quickly if there is a break-in.
Use different accounts on each server and so if an attacker starts fingering an account or trying to connect to that account on any server, say larry.smythe, you know which server they had to have found that on.
You wouldn’t even have to keep a table of which accounts are on which server. If you have N servers, assign a unique id number 0 to N-1 to each. Generate a simple hash of the username plus an internal string, divide the hash by N and use that address on the server with an id number equal to the remainder. Then if you see someone trying to log into that on any server, use the same process to get the remainder and you will have what server they got the account from since there would be no mention of larry.smythe on any other server.
These issues are tough. Even security firms get it wrong on occasion.
These are all good lessons learned that can benefit the rest of the community.
Ian
“…the attackers also stole the name and email address for nearly all of its customer support users”
But of course they did.
Was there ever any doubt that the initial damage control statement was nonsense?
It seems to me that the Otka employee could have been using MFA to login to whatever control panels they had access to. A simple password shouldn’t be enough to compromise the system. To login to even see that stuff should require MFA.
Even *I* use 2FA on sites that allow it, and have it enforced for any privileged users on anything I own.
My bet is that there is MFA protecting the user’s account in the control panel but, once in and working with service accounts, it may be very easy to accidentally allow your browser to store a password.
The article seems to suggest network admins should be able to disallow logging into private Google accounts on web browsers but that’s not a capability I’ve heard of. Can an admin disallow password saving in web browsers across the board?
All too often companies use 2FA to log on to a site, but once in, you have free rein over everything. Sensitive operations should also require 2FA authorization.
Are we not concerned that the senior security editor at Ars Technica has never even heard of a service account?
“One way of doing this is to put a limit or conditions on the IP addresses that can connect. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.”
None of these precautions are achievable by Okta “senior people”, only by customers; wth is going on at Ars Technica?
I think you need to re-read the article. If these precautions were taken by Okta the breach would have been prevented with no customer data or session cookies stolen. Amateur hour stuff for a company in IAM/Security space, hard to believe Internet access on the laptop wasn’t restricted not even a secure corporate configuration on the browser. Okta could still be blissfully unaware of the breach but for the persistence of one of their customers.
Umm, yes they are. The article is about “Okta Corporate,” nothing to do necessarily with Okta customers. Try to keep up! This is the admins at Okta Corporation si, yes, such practices would have prevented this.
Huh, a security company that can’t be bothered with User Behavior Analytics.
Shocking.
Why does a hacker having the names and email addresses of Okta customer admins really matter? I can scrub LinkedIn for the same information? To me, this is a perfect example of bikeshedding – or a slow news day.
Trusting your security to salespeople again??
I just purchased 1Password, but I am in the 14 day trial period. I then came across this article regarding the okta hack. I’m not an expert so I have to ask those who commented above. Should I continue with 1Password or not? What alternatives do you recommend?
ANY password manager is better than none at all unless you are some kind of savant. You still need to update passwords though. But pick long ones you could not possibly remember. Also it’s good to print out a list of them now and then and stash somewhere extremely safe/fireproof. Then at least you can get a start on rebuilding if something goes south.
“ANY password manager is better than none at all” – lol, no.
What does that have to do with Okta???
Good
By reading this , Incident I saw that Okta played wisely in this scam or incident because most of the company got hyper if this ever happened to any company but Okta handled carefully. Okta save it’s customers information. I Like this