In this two part series, we are going to analyze the role IdPs (identity providers) have played in some high-profile breaches over the last few years and perhaps, more specifically, the last few months. We will briefly look at the history of identity providers in on-premise environments, what they aimed to ultimately solve and how they have evolved in the cloud. We’ll then look at how the centralized convenience they offer, as well as the measures that have been put in place to secure their systems have ultimately been exploited by threat actors in the last few years. In the second part, we’ll review a timeline of breaches over the course of the last two years, why identity providers aren’t enough to secure identities across multiple layers of a cloud environment. We’ll also offer a few tips on steps you can take in order to better defend against common attacks orchestrated against identity providers.
In the last six months, Azure AD, Okta and JumpCloud have been at the center of breaches that impacted a number of their customers. Identity providers been the target of threat actor groups like Scattered Spider and even nation state threat groups. The tactics behind these breaches include purchased credentials, SIM swapping, spear phishing, compromised third party contractors and support agent identities, and sophisticated social engineering attacks.
So the other week, when Okta stated it suffered a breach in its customer support system, many members of the security community began voicing their frustration and disappointment in the lackluster response to the host of security incidents identity providers have been at the center of over the last two years.
So how exactly did we get here? How do SSOs/identity providers manage to find themselves at the center of high profile breaches? After all, almost any company can be the target of social engineering attacks, MFA bypass or third party contractor risk - that isn’t something unique to identity providers. What is unique is that, unlike other target victims, once a threat actor is able to gain access to an IdP instance, they have gained access to all the applications housed in that instance. It’s pretty much keys to the castle. And if someone is able to compromise an identity that has access to multiple IdP customer accounts (third party contractor, support agent), the impact is devastating. And because many threat actors will do their diligence by targeting a user who has an identity with admin-level privileges or close to it, their permissions allow them to complete their mission in short order.
Historically, Identity Providers Were Built to Manage Identity Sprawl
When identity providers were originally built, they were designed to help organizations managing the growing number of identities in their network. First generation IdPs were deployed in on-premise environments to provide centralized authentication and authorization across disparate systems. Solutions like OpenLDAP and Microsoft Active Directory were often the corner stone of managing identities in on prem environments.
As organizations accelerated their adoption of cloud through the first large waves of digital transformation efforts over the last fifteen years, legacy on-prem identity providers simply couldn’t be repurposed for the cloud or the SaaS applications built in the cloud. Second generation IdPs offered the ability to unify identity authentication and authorization across boundaries in the cloud.
Identity Providers Are Becoming Another Victim of Credential Compromise
By centralizing authentication through an SSO provider such as Okta, Ping, and Auth0, organizations more effectively manage identity sprawl, in addition to the security risks typically associated with disparate users and passwords across several different applications. By enforcing multi-factor authentication into the single-sign on process, second generation identity providers brought a greater layer of security to enterprises that federate their employees access, all while managing the underlying identity sprawl issues in the cloud.
As identity providers matured in the cloud, so did the tactics, techniques and procedures of threat actors who were able to take advantage of the vulnerabilities in the IdPs security protocols. The convenience that centralized authentication and access offers also presents a significant security risk. The credentials that drive SSO access are ultimately credentials that can be compromised for account takeover. These credentials are readily available in underground marketplaces where threat actors are able to simply purchase them as opposed to having to harvest them. In their Threat Hunting report earlier this year, Crowdstrike noted a 147% increase in access broker advertisements for credentials for sale in criminal or underground communities. The sharp increase in the number of credentials being sold in these marketplaces is undoubtedly a direct reflection of the demand threat actors have for these creds.
MFA Is Being Bypassed with SIM Swapping and Push Fatigue
Once an identity has been compromised, whether that’s through the purchase of a credential on marketplace, Phishing or credential stuffing, the threat actor still has to figure out a way to bypass the MFA in order to gain access to the IdP environment. Two tactics often used in this scenario are push fatigue, where the threat actor will inundate the target identity with a barrage of MFA authentication requests until they finally hit ‘accept’ to get the notifications to stop. The other technique often used to bypass MFA is SIM swapping. For those organizations that allow for SMS messages as the second factor for multi-factor authentication, the attacker is able to convince a support agent to transfer the mobile account to a number/device that they have control over.
At this point, the attacker now has the credentials needed to login to the targeted identity account, they have control over the second factor to bypass MFA and now have access to an admin level account in the IdP and all of the applications housed within that instance.
Identity Providers Are Becoming A Significant Third Party Supply Chain Risk
So what does this all amount to? Given the centralized access to a library of sensitive application and the ease in which threat actors are able to bypass security protocols to gain access to those environments, identity providers are becoming another third party risk in the cloud’s supply chain. This isn’t just that these IdPs are software providers in the cloud’s supply chain for tens of thousands of customers that use their service, but more so the access their outsourced support teams have that has been at the center of the breaches in the last few years. A company can maintain near perfect security posture and hygiene in their IdP instances in order to maintain a secure and compliant environment. They can put all of the right processes in place and successfully prevent threat actors from gaining access to their environment.
But as long as the IdP's support team, particularly those third party support entities where they have less oversight into, have access into any number of customer environments, their customer (users) remain vulnerable to a breach in the future. The access these support agents have, coupled with how easily they have been compromised in the past, poses a significant third party supply chain risk to any IdP customer, leaving a lurking, ongoing fear that security risk that goes unaddressed with the identity provider poses some downstream risk to their customers.
Up Next
In the second part of this blog series, we will look back at some of the breaches of the past few years, discuss some addition complexities that exacerbates these vulnerabilities, and offer steps an organization can take to depend less on identity providers to secure their identities in cloud environments.
