Identity Security: The problem(s) with federation

The last blog post explored non-human identity (NHI) security challenges, identifying identity federation as a major attack vector. Today, we’ll take a deeper look into federation-based threats, drawing on public research and historical breaches.

Notably, threat groups like APT29 and Scattered Spider frequently employ these techniques to maintain persistence and escalate privileges within their victims’ environments.

Identity federation vulnerabilities impact both users and non-human identities, and this post will address both as the attack vectors are often similar.

What is identity federation?

At its core, identity federation allows multiple services to perform access control by trusting an authentication performed by a different service (generally the identity provider). This diagram offers a schematic representation of the process:

The three most common protocols that allow identity federation are:

Security Assertion Markup Language (SAML)
Kerberos
OpenID Connect (OIDC)

Federation can occur between a variety of applications; for example, between an IdP and a third-party SaaS provider like AWS or Snowflake, or even between two IdPs (e.g., Active Directory to Entra, or Entra to Okta). A frequent use case is your CI/CD platform (e.g., GitHub) federating with a cloud service provider (CSP) to deploy code.

While the underlying protocols are complex, the key takeaway is that federating trust opens new avenues for attacks, especially if the federated relationships are exploited.

What are the threat vectors?

At a very high level, most of the federation issues can be seen as variations of the confused deputy problem. In other words: by delegating trust, we open up to an attack scenario where the adversary can compromise the IdP or install a fake IdP and leverage it to breach or maintain persistence in any environment that trusts the IdP. Note that this vulnerability is often transitive; for instance, if AWS is federated with Okta and Okta is federated with AD, compromising AD can lead to a breach in AWS.

These known attack patterns have also been observed involving federation:

Rogue federation
Token forgery
Federation misconfiguration

The following sections describe an example of each attack pattern.

Example 1: Scattered Spider’s rogue federation attack on Okta

Scattered Spider is one of the most prolific attackers when it comes to Okta-related intrusions. Scattered Spider’s approach is often very simple: first, they compromise a privileged Okta account via MFA fatigue and phishing, then, they proceed to persist in the system by adding a rogue federated IdP into Okta. Once the rogue IdP is registered, the attacker can log in as an existing Okta user into any application the user has access to. Note that because the IdP is attacker-controlled, they can impersonate any identity of their choice.

This video from Adam Chester shows a proof of concept of the attack leveraging SAML for federation.

Thankfully this attack is also reasonably easy to detect, since Okta emits an event when a new IdP is federated(system.idp.lifecycle.created) and it’s a low frequency event.

A variant of this attack worth mentioning leverages a valid compromised account in the IdP to breach a user in a third-party application. The attack happens by changing the login/username of the compromised user in Okta to a valid user in the third-party application.

For instance, let’s imagine a compromised Okta user account called user_A and a different Salesforce user [email protected]. The attacker can change the email address of user_A to appear as [email protected] when federated into Salesforce and hence impersonate the admin account without having access to it.

In Okta, you can monitor for the application.user_membership.change_username event. While not very common, it is a valid action sometimes used for governance purposes by IT teams and therefore it is important to monitor the event in combination with other contextual indicators.

Example 2: Token forgery – a quieter approach

The less noisy way to achieve the same goal is via token forgery. This attack has different names in different environments, the most famous one being “Golden Ticket” in the context of Kerberos and Active Directory. However, this attack is not restricted to any one specific protocol or IdP as it’s based on compromising the key used to generate authentication tokens.

In most federation mechanisms, trust between systems is established by registering a certificate or public key representing a third-party federated system. Once that’s done, an application can verify the authenticity of an incoming token by verifying its signature.

An attacker able to compromise the signing keys of an IdP is thus able to forge arbitrary tokens and impersonate any user within the system.

Several high-profile attacks employed token forgery. For instance, both the MGM Resorts hack and the Sunburst APT29 campaign leveraged token forgery to move laterally and breakout.

As mentioned, there are several variations of this attack but two common ones are:

Compromise an on-prem Active Directory domain controller and take advantage of identity federation to move laterally to Entra or to another system in the cloud
Add a rogue certificate or key pair to a legitimate federated IdP

Unfortunately, detecting token forgery is much harder than detecting a rogue IdP. Detection requires monitoring anomalous tokens and early detection of high risk indicators consistent with a potential breach.

Token forgery attacks are extremely powerful both because they are harder to detect and because they allow the impersonation of any identity.

Example 3: Federation misconfiguration

Federation can also introduce risk due to misconfigurations, especially in cloud environments.

Taking AWS as an example, every role has a role trust policy that defines who can assume the role and as a result perform any action the role is entitled to. The most trivial example of a role trust policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

In the policy above, any AWS account within the same account identity can assume the role.

It is also possible to authenticate to a role through an external identity via two actions: sts:AssumeRoleWithWebIdentity and sts:AssumeRoleWithSAML. The former is used for OIDC and web providers and the latter for SAML

Writing secure policies is far from trivial; consider for example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/40D159CDF6F2349B68846BEC03BE0428"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/40D159CDF6F2349B68846BEC03BE0428:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

In the role trust policy above, only an EKS cluster with id 40D159CDF6F2349B68846BEC03BE0428 can assume the role via AssumeRoleWithWebIdentity. However, the policy does not specify which identities can assume the role, which means that any valid access token is going to be able to assume the role.

These issues are present both for AWS-emitted tokens as well as token emitted by third-party IdPs that are registered with AWS (e.g., Github).

Similary to token forgery, there is not simple way to detect these issues and thus a comprehesive, contextual approach is necessary.

Conclusion

This blog post reviewed why identity federation is yet another source of identity-related breaches. SlashID can detect and automatically respond to the federation attacks shown above! If you are concerned about these attack vectors, talk to us to schedule a free Identity Security Assessment.