Trust but Verify — How to Secure Identity Provider Trust Relationships
Despite their best intentions, organizations find themselves contending with all too common admin sprawl throughout their apps and environments, leaving them with far more admins than they can handle securely.
Even as they try to limit this number in line with the Principle of Least Privilege, cutting down on privileges where they can, most organizations face an uphill battle when it comes to reducing the amount of privileged users with sensitive access to their valuable resources.
This state of affairs applies to widely used apps and infrastructure like AWS, Azure, GitHub, and Salesforce, just to name a few. It is also a common problem inside of popular Identity Provider (IdP) Okta.
As one of the leading IdPs, Okta plays a critical role in helping organizations to manage their identities and access with helpful features like Single Sign-On (SSO), Adaptive Multi-Factor Authentication (MFA), and Lifecycle Management. Okta provides high flexibility and openness to its customers, ensuring simple deployment and great user experience.
Due to its centrality for gaining and managing access to most if not all of an organization’s apps, Okta’s open and flexible configuration can be exploited by malicious actors to escalate their privileges inside Okta and across managed applications.
In this blog, we will detail the first of a series of common IdP misconfigurations identified by Authomize’s security research team, and how to mitigate your risks.
Segmentation of Admins within Okta
There are various categories of admins within Okta. These include super admins, org admins, app admins, and the like. Each with their own set of capabilities that are restricted as you move down the hierarchy of admins.
At the very top is the super admin.
Next comes the Org admins, who are similar to the super admins but with some limitations.
Follow down the hierarchy ladder and each rung will have fewer and fewer capabilities.
With all this great power comes great responsibility. Therefore we try to keep the total number of super admins fairly small in hopes that we can reduce our overall risk.
By comparison, according to Authomize’s researchers, most organizations have 2-3x the number of org admins to super admins.
The problem however is that in some cases the seals segmenting the different admin tiers is not as tight as we expect it to be. In practice, this means that those org admins can quickly and easily become super admins, greatly expanding the number of top level admins within the organization.
Explained below is how they can level up their privileges.
3 Steps to Escalate Privileges
In research recently released by the Authomize Security Research team, we have uncovered a configuration that can permit a malicious actor to make changes in Okta that will allow them to become super admins and gain persistence.
Here’s how it works:
- An org admin can configure a new IdP or modify an existing IdP (for example, one that was created a while ago but isn’t currently used) that is controlled by them
- Then, the org admin can add a new rule to the IdP, enabling certain users (for example, a super admin), to bypass any MFA requirement, making it significantly easier for attackers to gain access
- Lastly, the org admin can configure the IdP such that it authenticates as any user (for example, a user that is a super admin) in downstream applications
By having privileged access inside of Okta, the attacker achieves a level of persistence that can make them a continued risk within Okta and to the downstream apps until they are removed and the configurations are remediated.
Hidden Risks in IdP – Downstream App Trust Relationships
Okta plays key roles as hubs of trust between the upstream data sources (like HR systems, other Okta spokes, and other IdPs like different Okta instances or even other IdPs like Azure AD, and PingOne) and downstream applications like AWS, Azure, Salesforce, GitHub, and everything else you own, build, and use in the cloud.
This trust arrangement where Okta is the grease that makes IAM ops run smoothly, removing plenty of frictions along the way. But it also means that any malicious changes to privileges or IAM configurations throughout the chain of trust can impact systems downstream.
Given these stakes, we need to take risks that can grant privilege escalation to become a super admin quite seriously.
Reducing the Risk of Exploitation
Authomize’s security team offers the following tips and steps for reducing your risk of a significant breach and exploitation of your Okta.
- Continuously monitor your IdPs and remove stale IdPs whenever possible. You should aspire to have only the IdPs you need connected to your environment.
- Continuously monitor your org (and app) admins and make sure you use Just Enough Access for them. Consider if some of them can have their privileges lowered to read-only admins or even regular users? Make sure you are aware of org admin privileges granted through groups or custom roles.
- Prevent super admin login except using local IdPs. This will limit the risk of who can impersonate a super admin in your environment.
- Enforce IdP regex rules across your IdPs. This will differentiate the users logging per IdP and limit the risk of impersonating users outside of the IdP spoke.
Responsible Reporting
As responsible members of the Identity Security community, we shared the potential privilege escalation research and the content of this blog with our colleagues at Okta.
Okta strongly recommends customers take advantage of custom admin roles to create administrators who cannot manage a user with a super admin assignment. The linked resource that Okta provided has useful tips and guidance that will help you manage your administrators more effectively.
Balancing Efficiency and Security
Building great products that serve your customers and make them more effective is always a challenge because it requires balancing between competing interests.
This is true of every product, and it is generally the right call. As consumers of great products like Okta, we want the good folks over there to design their platform in a way that will give us the flexibility and capability to manage our identities quickly and efficiently.
What it means though is that Okta, like every other bit of critical infrastructure we depend on — think about your endpoints, network, and cloud — needs an additional layer of security to ensure that it is not being exploited.
As the leading Identity Threat Detection and Response (ITDR) Platform, Authomize can help your team to fill in that layer of security, closing the gap for a more secure IAM.
Start Securing Your Okta with a Free Assessment
Authomize is now offering a Free Assessment of your cloud and IAM infrastructure that will detect misconfigurations, posture risks, and even potential activity targeting your identities. Our Identity Threat Detection and Response (ITDR) Platform enables your organization to protect against Identity-based threats like those outlined in this post.
To learn more about Authomize and ITDR, request a complementary copy of Gartner’s “Enhance Your Cyberattack Preparedness With Identity Threat Detection and Response” report.
The post Trust but Verify — How to Secure Identity Provider Trust Relationships appeared first on Authomize.
*** This is a Security Bloggers Network syndicated blog from Authomize authored by Gabriel Avner. Read the original post at: https://www.authomize.com/blog/trust-but-verify-how-to-secure-identity-provider-trust-relationships/
