Summary
Microsoft has developed mitigations for an insecure anti-pattern used in Azure AD (AAD) applications highlighted by Descope, and reported to Microsoft, where use of the email claim from access tokens for authorization can lead to an escalation of privilege. An attacker can falsify the email claim in tokens issued to applications. Additionally, the threat of data leakage exists if applications use such claims for email lookup.
Microsoft recommends never using the email claim for authorization purposes. If your application uses the email claim for authorization or primary user identification purposes, it is subject to account and privilege escalation attacks.
Developers should review the authorization business logic of their applications and follow the guidance outlined below to protect applications from unauthorized access. We additionally encourage all developers to follow these Microsoft identity platform best practices for token validation. If you use third party applications, I.e., ones which you are not the developer, we encourage you to ensure your vendors are adhering to these best practices also.
We recommend reviewing your application’s source code and ensuring emails are not used for primary user identification or authorization. Please use the following migration guidance if your application uses either of these insecure patterns to eliminate the risk of account escalation attacks.
Customer Impact
Microsoft has identified several multi-tenant applications with users that use an email address with an unverified domain owner. Although unverified email addresses do not pose a risk to applications that do not utilize email claims for authorization purposes, these application owners have been notified and were provided with guidance on how to modify their applications, if applicable. If you did not receive a notification, your application has not consumed email claims with unverified domain owners. To protect customers and applications that may be vulnerable to privilege escalation, Microsoft has deployed mitigations to omit token claims from unverified domain owners for most applications.
Technical Details
AAD users without a provisioned mailbox can have any email address set for their Mail (Primary SMTP) attribute. This attribute is not guaranteed to come from a verified email address. An AAD user can be created or modified by a privileged user with an email which impersonates another AAD user. When an application uses an unverified email claim for authorization, a bad actor has the potential to gain unauthorized access by issuing a token to impersonate a valid AAD user.
While this is possible for a rogue admin to do within a single tenant app, the risk is mainly with multi-tenant applications where this misconfiguration could result account and privilege escalation.
Guidance on Securing your Azure AD Applications
Applications should never use the email claim for authorization due to its mutability and non-uniqueness. Addressing this vulnerability requires fully removing any business logic where email claims are used for authorization.
Microsoft recognizes that updating applications in this manner takes time and shorter-term mitigations are necessary. If your application is actively using the email claim for authorization, we recommend referring to the following documentation which provides guidance on migrating away from email claim usage, as well as outlining mechanisms Microsoft is releasing to mitigate risk.
Microsoft recommends reviewing application source code and verifying this insecure pattern is not used. Fully securing your applications against this incorrect authorization pattern requires changes to application source code.
Developers should always follow the published documentation on best practices for claims-based authorization. If your application is currently impacted, please review the guidance on short-term risk mitigation and migrating away from email claims.
Acknowledgments
We appreciate Descope for responsibly disclosing this insecure pattern and allowing Microsoft the time necessary to investigate the issue and develop appropriate mitigations. We encourage all researchers to work with vendors under Coordinated Vulnerability Disclosure (CVD) guidelines and abide by the rules of engagement for penetration testing to avoid impacting customer data while conducting security research.
References
Questions? Open a support case through the Azure Portal at aka.ms/azsupt.
Descope’s Blog Site: https://www.descope.com/blog/post/noauth
Identity and Network Access Standard’s Guidance: The False Identifier Anti-pattern
Identity and Network Access Migration Guidance: Migrate away from using email claims for user identification or authorization
Open ID Connect Core Specification for Standard Claims: https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims