Microsoft “nOAuth” is Vulnerable to Simple Email Spoofing

In June, researchers revealed a vulnerability in Azure Active Directory and third-party apps called “nOAuth,” that could result in a complete account takeover. This is just one of the many vulnerabilities in Microsoft software and systems like Active Directory that can be exploited, putting organizations at risk. Although Microsoft has responded to the vulnerability, developers must make code changes in their applications, and organizations need robust identity protection to prevent misuse of privileged accounts by rogue admins.

What is OAuth?

The name “nOAuth” is a Microsoft implementation of the OAuth authorization protocol. OAuth supposes that the identity provider will send the app you’re trying to authenticate in a set of data that is needed to log in. This information should also contain a unique identifier that prevents spoofing the login attempt.

The advantage of using OAuth is its convenience when you use dozens of services. As you need only one account to log into everywhere, there’s no need for remembering passwords to all of them. It is possible to revoke permissions anytime if you no longer want the application to access your resources. You have probably used it at least once, if you have Google, Apple, Facebook or another account. Anytime you see the option to “Log in with Microsoft” or “Log in with Facebook” – that’s it.

nOAuth Vulnerability Allows Email Spoofing

Researchers found a “nOAuth” vulnerability, which sits in the trust between Azure AD (identity provider) and an application (relying party). In Azure AD scenarios, anyone can easily generate that claim by simply spoofing the email address. This is possible for 2 reasons: Azure suite allows for changing email address domains even without domain ownership validation. Also because of the use of email address as a user identifier in the “nOAuth”.

What’s the Azure misconfiguration?

The issue originates from a misconfiguration that enables malicious actors to modify email attributes in Azure AD accounts’ “Contact Information” section. Attackers can hijack victim accounts by exploiting the “Log in with Microsoft” feature. To execute the attack, the adversary must create and access an Azure AD admin account, change their email address to the victim’s, and take advantage of single sign-on functionality on a vulnerable application or website. If the targeted application combines user accounts without proper validation, the attacker gains complete control over the victim’s account, even if the victim does not have a Microsoft account. This allows the attacker to establish persistence, extract data, and perform other post-exploitation activities based on the app’s functionality.

The screenshot below shows two different OAuth logins to the same application, with all claim values being the same except the “email” claim.

The mutable and unverified nature of email addresses causes the vulnerability in Azure AD. Microsoft does not recommend email claims for authorization.

How to counter identity-based attacks in AD and Azure AD ?

Microsoft has released guidance for developers to address vulnerabilities in their apps. The company recommends against using email claims for user identification or authorization and instead suggests following best practices for token validation. Additionally, developers should review their app’s source code to check for incorrect auth patterns.

To ensure your authorization logic is secure, validate the following information in claims:

• The actor (client app) is authorized.
  A client application acting on behalf of a user must be authorized. Use the SCP claim to validate permissions, limited to users’ needs and least privilege principles.
• The token’s tenant ID matches the storage location’s ID.
  Always verify that the token’s TID matches the ID used to store application data. Data stored in the context of a tenant should only be accessed within that tenant. Never allow data from one tenant to be accessed by another.
• The token specifies the intended audience.
  The AUD claim specifies the intended audience of the token. Before validating claims, always verify that the value of the aud claim in the access token matches the Web API – since the value can vary depending on how the client requested the token.
• The subject of the token is appropriate.
  Determine if the user or application is authorized by checking specific claims for SUB or OID or if the subject belongs to a relevant role or group using ROLES, GROUPS, and WIDS claims. Use the TID and OID immutable claim values as a combined key for application data and user access.