Executive Summary

The Obsidian Security Research Team has uncovered a persistence attack vector, Shadow Linking, which allows threat actors to gain persistent access via OpenID Connect (OIDC) login to victims’ SaaS accounts stealthily. Employees may also abuse this technique to maintain persistent access to company resources even after their offboarding. Many applications lack adequate defenses against such attacks, posing significant challenges for both individuals and organizations. This issue affects a number of popular SaaS applications, including but not limited to OpenAI, Zoom, Slack, Atlassian, Twitter, Expensify, and Notion. 

Background

Numerous SaaS applications have adopted Single Sign-On (SSO) services for their authentication flows. Social Identity providers (IdPs) such as Google, Apple, Microsoft, and Facebook are trusted and widely utilized by countless applications due to their prevalence.

However, our research shows that applications often incorrectly integrate with these IdPs, undermining the security of the SaaS applications, with two key components leading to the outcome.

Arbitrary Email Address Registration on IdPs

It is often underestimated how organizational email addresses can be used to register with nearly every identity provider. Even though an email address is managed on Google Workspace, it still can be used to register on other identity providers like Apple, and Microsoft.

Personal email addresses managed by one identity provider can also be used to register accounts on another. For instance, a Google email address (e.g. gmail.com) can be used to register an Apple account and a Microsoft email address (e.g. outlook.com) can be used to register a Google account, etc.

In fact, you can register on any of the common identity providers with almost any email addresses, regardless of their origin. The registration process only needs one-time proof of possession, typically by presenting a verification code sent to the email. 

OpenID Connect

OIDC is an authentication protocol built on the OAuth 2.0 framework (RFC 6749). As one of the most widely implemented SSO protocols, OIDC is utilized by numerous identity service providers and integrated into a myriad of applications to facilitate third-party authentication.

OIDC primarily secures the user authentication process by enabling applications to authenticate users through third-party IdPs such as Google. Upon successful authentication, the IdP issues an ID Token containing the user’s basic information to the application. This token serves as proof of the user’s identity. However, it does not specify how applications should use the ID Token for user identification and account linking. The application bears the responsibility for mapping the received ID Token to the corresponding internal user accounts.

Discrepant Dependency on ID Token Claims

An ID Token, issued by identity providers in JSON format, contains multiple claims that convey the user’s basic information, such as name, ID, and email address. Applications leverage these claims to authenticate end-users. A typical ID Token issued by Google’s identity service exemplifies this structure.

However, despite OpenID Connect emphasizing that applications should uniquely identify users using the sub claim (a unique identifier for a third-party account), as defined:

“The sub (subject) and iss (issuer) Claims from the ID Token, used together, are the only Claims that an RP (relying party) can rely upon as a stable identifier for the End-User. All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users.”

This approach is not always honored and widely adopted by applications.

Shadow Linking

Many applications, such as OpenAI, rely on the email claim to uniquely identify users and link user accounts. To put it into perspective, for a user possessing a OpenAI account registered with an email address ([email protected]), if a shadow social IdP account, say Apple, created with the same email address ([email protected]), is used to authenticate to OpenAI via Apple OIDC login, it will be authenticated as the same account without any additional verification, indicating that Apple account is magically linked to the victim’s OpenAI account.

From this observation, we concluded that regardless of which third-party identity service the user signs in from, as long as the email address of the third-party end-user matches one of the internal accounts, OpenAI links and merges the third-party end-user with that internal account without any further verification. This behavior is observed in many applications.

This is problematic. Consider two scenarios where this behavior can pose significant security risks:

1. Email Account Compromise: A threat actor compromises a victim’s Gmail account and registers accounts on Apple, Facebook, Microsoft, and other IdP providers using the victim’s email address. Since these third-party accounts are managed entirely by the threat actor, and email verification only occurs once during the registration process, the threat actor can use these accounts to access all the victim’s resources, both personal and organizational, even after losing access to the victim’s email. Note that this a more severe problem than abusing the account linking feature to persist manually in individual SaaS applications since it does not require compromising the SaaS account, and it also allows the takeover of future SaaS accounts that don’t exist at the time the threat actor taking control over the email.
2. Organizational Member Abuse: A Google Workspace organizational member can register accounts on Apple, Facebook, Microsoft, and other IdP providers using their organizational email address. These third-party accounts are managed entirely by the user, not the organization, and email address verification only happens once during the registration process. This allows the organizational member to use these accounts to access the organization’s internal resources in numerous applications, even after they have off-boarded from the organization.

An application granting an account session to a third-party end-user based merely on an email address without additional verification is what we call Shadow Linking. Based on our tests, Shadow Linking happens almost everywhere. One compromised third-party account can act as a skeleton key, “shadow linking” to numerous applications, working perfectly in terms of persistence.

Test Cases

During our research, we tested nine different popular applications, both individual and enterprise versions, assuming they use OIDC authentication (which they do by default).

Our observation reveals that 7 out of 9 applications are vulnerable to Shadow Linking. The test results are summarized below: 

Application	Identification Claim	Vulnerable to Shadow Linking (without 2FA by default)	Vulnerable (with 2FA enabled) / 2FA Bypass	Set 2FA Without Extra Verification	Manage IdP Links (disable or occupy)	Modify Email Address	Cost to Enable SAML SSO
Zoom	Email		(basic) (pro-)	(basic) (pro-)			$21.99/month/user
Notion	Email						$15/month/user
Atlassian	Email						$11.75/month/user
Slack	Email						$15/month/user
OpenAI	Email						$60/month/user
Expensify	Email						$9/month/user
X	Email
GitLab	Sub
Shopify	Sub

Legend:
– Vulnerable
– Secure
– Not Available
(basic) – Applies to Zoom’s basic subscription
(pro-) – Applies to Zoom’s pro subscription and higher

Enforcing SAML SSO is the best practice to defend against shadow linking in the enterprise environment. However, SAML SSO is often only available as part of “Enterprise” pricing in applications. According to the “SSO tax”, vendors can charge 2x, 3x, or 4x the base product pricing for access to SSO, which disincentivizes its use by small businesses and makes them more vulnerable than larger companies.

We also explored the possibility of evading defenses and incident responses once shadow linking has occurred. Our findings reveal that many applications lack effective measures to actively defend against or mitigate the impact of shadow linking once it has been established. This gives the attacker opportunities to permanently dwell and even lock out the victim once the attacker creates their initial foothold. We will discuss this further.

2FA Bypass

Two-factor authentication (2FA) is intended to add an extra layer of security to applications. However, many applications place complete trust in third-party identity services and do not apply 2FA to SSO logins, even when users have enabled it. Based on our test results, 5 out of 7 vulnerable applications disregard 2FA when a user signs in via SSO. This oversight leads to serious security issues, allowing attackers to evade defensive mechanisms and maintain persistent access to the victim’s account.

For example, Atlassian explicitly states that two-step verification is not applied to third-party SSO logins.

Other vulnerable applications such as OpenAI, Notion, and Expensify, also ignore the 2FA policy for third-party sign-ins. 

Moreover, our test cases revealed that all vulnerable applications lack the functionality to unlink or disable a third-party account. This, combined with the 2FA bypass, provides attackers with a means to establish permanent persistence on the victim’s accounts once the attack occurs.

2FA Abusing

Our research also found that many applications do not require additional verification when setting up 2FA, as observed in our test cases with Slack, OpenAI, and Expensify. This insufficient verification allows threat actors to abuse 2FA to gain exclusive control over the target account, effectively locking out the legitimate user.

For example, OpenAI’s products, including the highly popular ChatGPT and its API platform, are vulnerable to both Shadow Linking and Multi-Factor Authentication (MFA) lockout attacks. OpenAI implements 2FA in a way that once 2FA is enabled, users must log in using the same third-party authentication method used during the 2FA setup. The setup process only requires verification of the currently signed-in third-party account, which is inadequate and creates a false sense of security.

As a result, attackers can easily exploit this feature to enable 2FA, thereby disabling all other authentication methods and achieving a full account takeover, leading to complete victim lockout.

Can users simply use their phone number or email address to recover the account? Unfortunately, OpenAI is phasing out phone verification and experiencing issues with email delivery. Furthermore, it is impossible to change the email address linked to the account. As of today, there is no way to recover an account once it has been taken over in this manner.

Detection

While detection is challenging, the blue team can still obtain valuable information from the user’s login activity logs. By analyzing the metadata from login events—such as the authentication method (password, OIDC, SAML SSO, etc.), the third-party IdP used, the IP address and the timestamp—the blue team can identify malicious activity by correlating these details with other compromises and events.

Through our research, we found not all vulnerable applications provide comprehensive logs to support detection. For example, Slack only provides access logs that describe the user login activity without details like login type and SSO sources. Other applications, such as Atlassian, do not even offer login-related activity logs. The lack of detailed login logs makes it hard to even have visibility into Shadow Linking. 

Obsidian Recommended Remediations

For Application Developers

• Link Third-Party Accounts Based on the Sub Claim

When an ID token with an email address that matches an existing account is presented for the first time, require the user to authenticate the existing account first or prompt the user to link the account through the user portal, rather than automatically linking and merging the third-party account with the existing account. Once authenticated, bind the account with the sub claim in the ID Token. This process ensures that the current user from the third-party service is indeed the legitimate owner of the account. Applications like GitLab and Shopify implement this method to effectively defend against Shadow Linking from the outset.

•  Provide Comprehensive Third-Party Linking Management

Enhance security by giving users transparency and complete control over the SSO linking process, including the ability to unlink third-party accounts and disable certain third-party sign-ins in both individual and enterprise setups. Our test cases showed that only 2 out of 9 applications offer sufficient functionalities to mitigate the Shadow Linking attack. 

• Apply 2FA to Third-Party Sign-In

When users enable 2FA, applications should also enforce 2FA for third-party sign-ins. This measure mitigates the Shadow Linking attack and addresses further 2FA abuse and bypass threats.

• Require Additional Verification Before Setting Up 2FA

Ensure that additional user verification is required when setting up 2FA through the user portal. This extra step confirms the user’s identity and mitigates 2FA abuse attacks.

• Support Detailed Login Logs for Security Audit

Ensure detailed login event metadata is recorded, including the authentication method (password, OIDC, SAML SSO, etc.), the third-party IdP used, the IP address and the timestamp.

For End-Users

End users should take proactive measures to mitigate the potential impact of Shadow Linking.

• Enforce 2FA

Enable two-factor authentication (2FA) on all accounts where possible.

• Set Up a Password

Setting up a password for an account can provide additional security similar to enabling 2FA. For instance, if you sign up for a Zoom account using an SSO option like Google, your account will not have a password by default. Setting up a password ensures that many operations, such as linking with a third-party account or enabling 2FA, require extra verification.

• Disable or Pre-link Third-Party Sign-In Accounts

Remove unused or unnecessary third-party sign-in options or pre-link owned third-party accounts to reduce attack vectors.

For IT Administrators/Corporate Security 

• Enforce SAML SSO Authentication

Implement SAML SSO authentication across all work applications. This centralizes the management of employee accounts and prevents external users from infiltrating application workspaces. It also reduces the burden on IT administrators to manually delete users’ accounts in various applications after off-boarding.

• Disable Unused Third-Party Sign-In Options

Disable any unused third-party sign-in options to block external users from joining the workspace.

• Enforce 2FA Policy on Managed Accounts

Ensure that all managed accounts have 2FA enabled wherever possible.

• Enforce Password Setup on Managed Accounts

Ensure all managed accounts have passwords set up, which can function similarly to 2FA authentication and provide additional security.

For Identity Service Providers

• Add Domain-Related Claim into ID Token

To prevent external third-party users from infiltrating organizational workspaces, identity service providers should support domain-related claims in their ID Tokens. This helps applications differentiate between personal and organizational users, similar to the hd claim supported by Google Identity services.

• Reject Work and Education Email Address Registration

Disallow the use of work or education email addresses for account registration. For instance, Microsoft and Apple already block account registration with many email addresses from major companies and renowned educational institutions.

Given the challenge of blocking all work or education email addresses for account registration, identity service providers should offer organizations a way to declare their domain addresses and specify whether their domain email addresses can be registered. For example, Apple ID could create a website where organizations can manually prove ownership of their domain by setting up a TXT DNS record and notifying Apple if users are allowed to register accounts with this domain.

Conclusion

The rise of Single Sign-On services has streamlined user authentication across numerous SaaS applications. However, as our research highlights, relying on these services can introduce significant security risks. 

Application developers must adopt robust security practices, such as linking accounts based on the sub-claim and providing comprehensive third-party linking management. End-users must remain vigilant, enabling 2FA and managing their third-party links appropriately. IT administrators should enforce stringent security policies, including SAML SSO authentication and 2FA policies, to safeguard managed accounts. Identity service providers also have a vital role to play by offering domain-related claims and rejecting the registration of work and education email addresses. 

By implementing these measures, we can collectively enhance the security of SSO integrations and protect against the persistent threats posed by Shadow Linking.

The post Shadow Linking: The Persistence Vector of SaaS Identity Threat appeared first on Obsidian Security.

*** This is a Security Bloggers Network syndicated blog from Obsidian Security authored by Rajeev Raghunarayan. Read the original post at: https://www.obsidiansecurity.com/blog/shadow-linking-the-persistence-vector-of-saas-identity-threat/