The Latest Okta Support Team Breach
Should you stop using Okta ~ or alternatively ~ what can you do to protect yourself?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: Okta Security | Data Breaches | IAM
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I’ve been performing an analysis of Okta recently and there are some pros and cons of segregating your Identity and Access Management to a platform separate from your other cloud providers. Whether or not you should do that depends on the platform, of course.
Okta has had a string of security issues recently so people may be concerned, rightfully so. However, the concern needs to be properly aligned with reality. So Okta had a breach. Where are you going to move all your identities instead?
One of the only other games in town that has been the primary provider of IAM for large organizations for years has been Microsoft Active Directory. Ever heard the term “Domain Admin?” Attackers and penetration testers have been breaking into Active Directory since it existed — often successfully — since it holds the keys to the kingdom. Once an attacker broke into Active Directory, they could create new identities with access to anything on the network and even lock out the administrator potentially.
Along came the cloud. Many companies that used Active Directory are moving their identities to Entra ID, the IAM service formerly known as Azure Active Directory. So you’re safe now, right? No. Stealing credentials from Entra ID may be harder to do if the service is configured with all Microsoft’s expensive security services.
Microsoft has some very helpful options for Entra ID and Azure if you pay extra — like a risky logins report and conditional access. You still have to configure those things correctly to block logins from unexpected networks and other risky factors. You need to architect your IAM and governance thoughtfully with security breaches, attacks, and blast radius in mind. It’s not magic.
Okta also has the concept of conditional access. I haven’t reviewed it yet in detail to see how it compares to Microsoft’s offering but I plan to do that in the future.
Microsoft has breaches too. Although Okta is getting hit very hard by this breach announcement, Microsoft has its share of breaches — and outages — as well. I wrote about some of those here because they seemed to be happening at an alarming rate, including 250 million support records exposed online.
Two wrongs don’t make a right — but what I don’t understand is why Okta gets hit with a loss of 2 Billion dollars in market cap and people hardly blink when Microsoft has a breach.
https://www.cnbc.com/2023/10/23/okta-hack-wipes-out-more-than-2-billion-in-market-cap.html
I think one of the reasons may be that Microsoft provides a very detailed analysis of exactly what caused the breach.
As suggested earlier on Twitter today, I think Okta could provide more details related to the breach such as:
- Were automation or user credentials compromised to access the support portal?
- If it was a person, were they using MFA and specifically hardware MFA that is not using seeds?
- Was Okta’s conditional access feature configured?
- Why did customers find the breach faster than Okta?
- Are any aspects of this breach within the scope of the current Okta bug bounty? Okta has a bug bounty but limits the scope to specific aspects of its systems.
- What is Okta doing to address this and ensure it can spot breaches of its own and customer systems faster in the future?
- Provide a detailed analysis of the attack path the attacker took, similar to the Microsoft breach above.
Maybe Okta is still working on providing a detailed analysis. They probably don’t want to face the criticism of the LastPass breach where the company dribbled out bits of conflicting information over time.
So hopefully Okta is working on and will release a more detailed report. However, unlike Microsoft, they have not stated they are going to do so, as far as I know at this time.
Should you stop using Okta?
I am partway through an Okta assessment. I can’t fully see into the service, the bug bounty program has some limitations due to scope, and the company has not hired me to do a full-fledged assessment so I cannot truly tell you everything about Okta. I do wish they had a few additional networking controls to keep traffic on private networks. But as far as this breach is concerned, that is irrelevant as far as I know at this point.
What matters in the case of this breach is the information that customers were providing to support teams. In fact, I wrote about the risks involved with giving information to support teams already in this post.
You’re trying to get something working in a system. A support team asks for whatever and your employees just give it to them without question. The problem is that sometimes the employees are handing over their own credentials.
In the post above, I explained how a request for debug logs for a cloud provider contained a session token that the support person (or anyone with access to that support system or the support person’s machine) could have used to access my account.
In the case of the Okta breach, customers are handing over HAR (HTTP Archive) files with credentials embedded in them. Even without a breach of Okta this is a risk because any malicious insider at Okta could use those credentials as well. Don’t do that!
There are many companies asking for HAR files all over the place. Here’s an example from Zendesk. I found many other support pages like this using a quick search. All those companies are now a target. At least Zendesk warns you about credentials in the files.
Sure this may make it easier to troubleshoot systems but so is handing over your credentials so the support person can log into your account. You’re not doing that right?
Companies need to train their employees how to interact with support teams without giving up sensitive data — and companies like Okta need to stop asking for that information when it is a risk.
Perhaps there would be a way in the future to change the HAR functionality to exclude sensitive data but that’s going to be difficult since each application might log sessions, tokens, and cookies in a different way.
An alternative to a HAR file would be a document with screenshots and a step by step process to reproduce the problem. The problem I’ve had — especially with Microsoft Azure over and over again — is that they have a place to upload a file but the support team never looks at it!
Companies need to have better support teams and that may require paying them more and providing better training and benefits. Support is a difficult job with a lot of churn and is often a stepping stone to some other job. Make it the job to get and employ some of your best people in support. Train them on how to interact with customers more securely.
The other thing is that sometimes people with nefarious intentions will infiltrate support teams — or be paid by bad actors — because it’s a way to get at things like HAR files, system vulnerabilities, and customer data that can be used later in attacks.
Do not take support teams and your interactions with them for granted.
Another thing I’ve noticed is that support teams will just immediately ask for documentation and files they don’t even need to solve the problem I’m asking. I once contacted Docusign support which I think was coming from some other country and every person I got asked me for a screen share before they ever even knew what the problem was. Um, no.
Screen shares involve a network connection into my network, through my firewall and router, only my machine by some sketchy software I don’t want to install. I have no idea what that video screen share program is actually capturing and I don’t care what you tell me it is doing and how secure it is. I don’t want it on my system. So no.
Architect IAM solutions with separation of duties, MFA, and limited blast radius
I’ve written a lot about IAM solutions that are architected to help prevent and limit the scope of a breach, including some specific Okta considerations in these posts:
If you have an administrator that can both create new users and assign permission to them you have an elevation of privilege risk. I explain how to prevent them by the way you architect your IAM solutions in general in the above posts and these Okta specific posts.
That may be how some of Okta’s customers identified the breach. I haven’t read yet but CloudFlare and BeyondTrust produced reports on how they discovered and limited the impact of Okta breaches.
Update: Just read this interesting tidbit about Okta security related to the BeyondTrust report.
The attacker was able to get around this by pivoting to using admin API actions authenticated with the stolen session cookie, something that Okta policies cannot be configured to stop. They used this technique to create a backdoor user account, but BeyondTrust identified and disabled it before it could be accessed by the threat actor.
Hopefully Okta will address that.
What should companies do better to provide support without sketchy files and risky access?
When you’re designing a system — test your system better first of all.
The QA team is also a team that is often underrated, underpaid, and employed with people of lower skill sets. Your QA team needs to be one of your best teams if you are providing sensitive security systems that provide services like identity and access management or a cloud platform.
I was looking at the Okta bug bounty recently and the scope is somewhat limited. Increase the scope to allow people to test all parts of the system, short of social engineering support people. Hire a penetration test or red team company for the latter as this has happened twice now (potentia.
Limit the blast radius
Figure out how to secure the data even if the support person or team gets compromised. How is encryption architected? Are these files being sent in email? Stop that. Block them. Make sure they are uploaded to a secure system that requires hardware MFA to access. Use an assume breach approach with the support team credentials and ensure that accessing one person’s credentials doesn’t expose customer data. Use segregation of duties and require two people to access sensitive data.
Companies need to implement better logging and error handling and useful error messages when system issues occur.
Doing so would limit the need to ask customers for sensitive information to resolve the problem.
I’ve referenced that article over and over again as I report bugs on my Bugs That Bite blog.
First of all, better error messages and better documentation is going to negate the need for the support call in the first place.
Systems that properly log errors with an error number and can link to the article for that error number that explains exactly how to fix it are going to save everyone a lot of time.
A single error should relate to ONE problem. If your error message could relate to a myriad of different things then you need more error messages — one for each potential problem. That means writing better software.
Companies need to better secure and test their support systems too.
It’s not clear from the breach notice whether the person whose credentials were stolen was using MFA or not, or even if it was a person. Those HAR files should have required hardware MFA to access since they contained customer credentials — or perhaps the system accepts the files and the credentials are tokenized upon receipt. Additionally, why were the HAR files not encrypted on disk? Or perhaps they were but the support person was using the system with an active session token. We don’t really know. There are too many unanswered questions to address the issue properly and speculation is kind of pointless. I hope Okta will provide more details so we can all learn from it.
Identity and Access Management Solutions Will Be Breached — Again and Again
IAM solutions will continue to be attacked and likely breached — no matter who your provider is — and it’s up to you to architect accordingly to limit the risk, and avoid sharing your credentials with support teams.
Also, keep pushing your provider to improve their solution and provide details about attacks and how both you and they can address them.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
