Microsoft has resolved a serious security vulnerability in Azure Active Directory (Azure AD) authentication. The flaw, known as “nOAuth,” which was revealed by the Descope security team this week, could allow malicious actors to escalate their privileges and even gain complete control of a targeted account. This misconfiguration in authorization of Azure AD OAuth applications using the email claim from access tokens could lead to dangerous account and privilege escalation attacks. It is crucial that users take immediate action to ensure their accounts are secure.
Risk of Account Takeover
As Descope´s team explained, the flaw lies in the authentication implementation of Microsoft Azure AD multi-tenant OAuth applications. They pointed out that a malicious actor could manipulate the Email attribute under ‘Contact Information' in the Azure AD account, thereby gaining control over the 'email' claim in the returned identity JWT. The team further elaborated that if an attacker creates their Azure AD tenant and uses ‘Log in with Microsoft' with a vulnerable app and a specially crafted ‘victim' user, it could result in a complete account takeover.
Descope found several large organizations vulnerable to this type of attack, including a design app with millions of monthly users, a publicly traded customer experience firm, and a leading multi-cloud consulting provider. These organizations have been notified and provided with guidance on how to modify their applications.
How Azure Ad OAuth Works
OAuth is a protocol for authorization that is used by Azure Active Directory (Azure AD). It allows a user, who is typically the resource owner, to grant limited access to their protected resources. This protocol is designed to work specifically with the Hypertext Transfer Protocol (HTTP), and it separates the role of the client from the resource owner.
The process works as follows:
- The client requests access to the resources controlled by the resource owner and hosted by the resource server.
- The resource server issues access tokens with the approval of the resource owner.
- The client uses the access tokens to access the protected resources hosted by the resource server.
OAuth 2.0 is directly related to OpenID Connect (OIDC), an authentication and authorization layer built on top of OAuth 2.0. However, it's important to note that OIDC is not backwards compatible with OAuth 1.0. Azure AD supports all OAuth 2.0 flows.
The nOAuth Attack Procedure
Descope provided a detailed explanation of the nOAuth attack flow. They explained that an attacker could simply change the email on their Azure AD admin account to the victim's email address and use the “Log in with Microsoft” feature for authorization on the vulnerable app or website. Descope warned that if the app merges user accounts without validation, the attacker could gain full control over the victim's account, even if the victim doesn't have a Microsoft account.
Microsoft´s Response
The exploitation of this flaw could enable threat actors to escalate privileges and potentially take over the target's account completely. The Descope team highlighted that this misconfiguration could be used in account and privilege escalation attacks against Azure AD OAuth applications that are configured to use the email claim from access tokens for authorization.
In response to the discovery, Microsoft has taken steps to rectify the Azure AD authentication flaw. The company acknowledged the issue and stated that they have developed mitigations for the insecure anti-pattern used in Azure AD applications. This issue was initially highlighted by Descope and reported to Microsoft. The company further emphasized that the use of the email claim from access tokens for authorization could lead to an escalation of privilege.
Steps to Mitigate the Issue
In response to the nOAuth configuration, Microsoft has issued mitigations. The company stated that to protect customers and applications that may be vulnerable to privilege escalation, they have deployed mitigations to omit token claims from unverified domain owners for most applications.
Moreover, Microsoft strongly advises developers to thoroughly assess their apps' authorization business logic and adhere to these guidelines to safeguard against unauthorized access. They also encouraged developers to adopt the recommended best practices for token validation when utilizing the Microsoft identity platform.
