Full Report
New research has uncovered continued risk from a known security weakness in Microsoft's Entra ID, potentially enabling malicious actors to achieve account takeovers in susceptible software-as-a-service (SaaS) applications. Identity security company Semperis, in an analysis of 104 SaaS applications, found nine of them to be vulnerable to Entra ID cross-tenant nOAuth abuse. First disclosed by
Analysis Summary
# Vulnerability: Persistent nOAuth Abuse in Microsoft Entra ID Consumer Apps Allowing Account Takeover
## CVE Details
- CVE ID: Not explicitly listed in the text. The vulnerability (nOAuth) was first disclosed in **June 2023**.
- CVSS Score: Not provided in the text. (Severity implied as high due to Account Takeover potential).
- CWE: Not explicitly listed, but related to improper implementation of OpenID Connect (OIDC) token validation, likely related to using incorrect identifiers (e.g., `mail` attribute instead of `sub` claim).
## Affected Systems
- Products: Software-as-a-Service (SaaS) applications relying on Microsoft Entra ID for authentication (specifically those utilizing the "Log in with Microsoft" feature via OpenID Connect).
- Versions: Any application whose developers have **not** remediated the implementation flaw two years after initial disclosure (9% of analyzed apps are still vulnerable as of the report date).
- Configurations: Applications where the "Log in with Microsoft" implementation uses an attribute other than or in addition to the `sub` (subject) claim combined with the `iss` (issuer) claim as the sole unique identifier for merging or authenticating users. Specifically targets cross-tenant scenarios where the attacker and victim are in different Microsoft Entra ID tenants.
## Vulnerability Description
The "nOAuth" vulnerability is a weakness in how certain SaaS applications implement the OpenID Connect (OIDC) authentication layer built atop OAuth. An attacker can exploit this flaw to achieve a full account takeover in a targeted SaaS application.
The core mechanism involves:
1. **User Impersonation:** The attacker modifies the `mail` attribute of an attacker-controlled Entra ID account to match the email address of a victim user.
2. **Authentication Bypass:** The vulnerable SaaS application uses this mutable `mail` attribute (or similar non-standard claim) as the sole criterion to uniquely identify and merge sessions, rather than relying strictly on the immutable `sub` identifier provided by the identity provider (Entra ID).
3. **Session Hijacking:** The attacker uses the compromised identity to log into the SaaS application via the "Log in with Microsoft" button, resulting in the attacker gaining access to the victim's account data within the SaaS environment. This can potentially allow pivoting to Microsoft 365 resources.
## Exploitation
- Status: **Still affects 9% of analyzed SaaS apps**, indicating continued risk and potential for dormant exploitation.
- Complexity: **Low effort**. The article states the attack is "trivial."
- Attack Vector: **Network**. Relies on the standard OIDC/OAuth flow over the network.
## Impact
- Confidentiality: **High**. Leads to access to sensitive SaaS application data and potential pivot to M365 resources.
- Integrity: **High**. Attacker can modify data within the compromised account.
- Availability: **Medium/High**. Depends on the specific application's functionality, but ATO typically implies full control.
## Remediation
### Patches
- No specific vendor patch is mentioned for the *SaaS applications* themselves, as remediation relies on developer implementation changes.
- Microsoft has reiterated recommendations from 2023 emphasizing that relying parties **must** use only the combination of the `sub` (subject) claim and the `iss` (issuer) claim as the primary account identifier.
### Workarounds
- Developers must update their OIDC relying party implementation to strictly adhere to Microsoft's specification, enforcing that the **`sub` claim** (combined with `iss`) is the only factor used to uniquely identify an end-user.
- Applications should avoid using mutable claims like `mail` as the primary unique identifier.
## Detection
- Indicators of Compromise: Look for unusual authentication events where user identities appear to "switch" or where sessions are established using accounts that possess email addresses matching previously known user identities but originate from unexpected or unverified source accounts.
- Detection methods and tools: Requires auditing the OIDC implementation within the relevant SaaS application's authentication logic to ensure adherence to Microsoft's OIDC guidance regarding identifier claims. Vendor-specific logging related to OIDC token validation errors or successful unique identifier usage might be relevant.
## References
- Vendor Advisories: Microsoft has emphasized guidelines regarding the "False Identifier Anti-Pattern" (use of claims other than `sub` + `iss`).
- Relevant links - defanged: hxxps://www.semperis.com/blog/noauth-abuse-alert-full-account-takeover/
- Relevant links - defanged: hxxps://techcommunity.microsoft.com/blog/microsoft-entra-blog/the-false-identifier-anti-pattern/3846013