Authomize, the first Cloud Identity and Access Security platform, announced its discovery of significant inherent security risks in Okta, one of the leading Identity Provider (IdP) services.
Authomize’s Security Research lab has uncovered that with a very limited level of privilege and practically no difficulty, a malicious actor can remotely:
- Extract all p******** in clear text
- Impersonate other users in downstream applications and hubs
- Alter their appearance in logs to hide their activity
All while gaining long-term persistence that will allow them to maintain access within the target.
Authomize’s CTO and Co-founder Gal Diskin describes the highly risky security exposures as flawed yet intentional designs that open the door to exploitation, and not simply a coding mistake. In their response to Authomize’s responsible disclosure, Okta has stated that they do not believe these security issues to be vulnerabilities, but functions working according to their intended design and expected inherent risks.
“Our team discovered these risky designs during the course of our research into Identity Providers,” says Diskin. “Following the news of the Okta breach earlier this year, we focused our efforts on understanding what sorts of actions a malicious actor could do if they achieved even a minimal level of access within the Okta platform. As we laid out in our technical write up of these major operational risks, we were very surprised to find that Okta’s architecture for password synching creates a situation where an actor can simply pull out p******** in clear text, even over unencrypted channels (HTTP), and including the p******** of more senior admins.”
Latest ITechnology News: SAS Recognizes Global Partners Driving Innovation in the Cloud
In detailing the security exposures, Diskin explains that all that is needed for extracting the clear text p******** is for an actor to gain app admin privileges. Given the constantly expanding number of users within organizations of all sizes, especially in enterprises, he says that the probability of an app admin being compromised is statistically quite high with the Verizon Data Breach Investigations Report for 2022 finding that 82% of beaches involved human elements like stolen credentials and phishing. More concerningly, these app admins are generally not treated as privileged identities. Diskin noted that this functionality serves a real legitimate purpose for Okta customers, but the exchange of p******** using clear text transmission over unencrypted channels goes against the accepted best practices in the security industry.
Okta’s Hub and Spoke architecture also leaves organizations open to exploitation. Spokes are meant to allow for segmentation between sub-groups or departments or even sub-contractors. However Diskin and his team discovered that a spoke admin, of which there are many within an organization, can easily impersonate another spoke admin within the hub if necessary controls, which are available from Okta but not explained or activated by default, are not implemented.
“Using this functionality an attacker, either internal or external, can impersonate other admins and achieve persistence within the hub and downstream apps that puts the whole organization at critical risk. It is important to note that the required security controls exist within Okta, just that rather than being secure by default and well highlighted in documentation, those are actually only mentioned in passing and not configured securely by default,” explains Diskin, adding that anyone, admin or not, can alter the way they appear in the logs to cover up their activity while impersonating another user or performing other unsanctioned activity.
“While some of these risks are Okta specific and definitely require some addressing I think that there is a more fundamental issue here which is that some attacks are inherent to the way modern Identity Providers, Enterprise SSO, and IAM tools work. The key here is that just like with CSPs, the Identity Providers need to enable third party security monitoring by providing relevant APIs and audit logs,” says Diskin.
Latest ITechnology News: Nokia Extends Strategic Partnership with Wipro to Drive Digital Transformation and Efficiencies
“There are immediate steps that both Okta and organizations can take to mitigate the risks that we have uncovered,” says Diskin. “The first step is for Okta to block the ability to export the master password for Okta user accounts, allowing instead only for the export of alternate p******** that is a much more secure option. Next is discontinuing the use of duplicate identities in their Hub and Spoke architecture, or at least making that the default configuration, and saving only the unique user identifier and not the mutable name in logs.”
“For their part, organizations need to apply monitoring to Okta to look for changes in configurations and the actual actions performed by users,” says Diskin, noting that it is essential to focus especially on the admins if they hope to catch a malicious actor in time to prevent damage or compromise.
“We are working closely with our customers to ensure that they are protected from being exploited,” says Diskin, explaining that, “Our research highlights the criticality for organizations to implement an independent security layer around their Identity and Access Management (IAM) tools like Okta, monitoring, validating, and detecting risks within these systems to ensure that the infrastructure systems that they depend on for managing their identities and access are not themselves used as as the route of exploitation by malicious actors.”
In response to Authomize’s responsible disclosure, Okta has confirmed that all of these risks are intentional design decisions, and does not consider them as vulnerabilities. However, they say that their product team will work to address the password leakage issue and will look into the other issues outlined in Authomize’s research that may impact their customers.
Latest ITechnology News: SafeGuard Cyber Delivers Context-Aware Response with Microsoft Azure AD and Okta
[To share your insights with us, please write to sghosh@martechseries.com]
