News

Microsoft Advises App Developers About 'nOAuth' Attack Route

• By Kurt Mackie
• 06/21/2023

Microsoft this week addressed findings by security researchers at Descope, who reported a "nOAuth" attack route that's present in some applications leveraging the Azure Active Directory service.

Essentially, application developers may be permitting the use of e-mail claims during authentications, which is not a recommended practice. Azure AD, which is based on using OAuth tokens and the OpenID Connect identity layer, had a flaw in that it allowed these e-mail claims to be "mutable" or changeable, namely by an attacker, Descope found.

Update 6/27: The first step for an attacker leveraging the nOAuth attack route would be to access "their [the attacker's] Azure AD account as admin," Descope noted, and then change their e-mail address to match the victim's email address. Descope was not saying that Azure AD admin privileges are needed on the victim's network to carry out the attack, according to Justin Schoenfeld, a senior cloud security researcher at security solutions firm Red Canary, via an e-mailed comment.

Here's how Schoenfeld explained the matter.

"An attacker leveraging the nOAuth attack route would need to have changed the email address of their AAD account in their home tenant to the same email address as the victim account which lives in the victim’s home tenant," Schoenfeld explained. "Then all the attacker would need to do is authenticate to the AAD application via the 'Login with Microsoft' button as usual using the attacker's home tenant account. In the background, vulnerable applications will use the attacker's account's email claim and incorrectly associate it with the victim's leading to a full account takeover."

Descope, on top of notifying Microsoft, also reached out to application and Web developers about the flaw. However, "the number of apps we tested are a drop in the ocean of the Internet," Descope indicated, so some apps may still be vulnerable.

The problem with Azure AD allowing e-mail claims to be mutable gets compounded when identity providers permit application users to leverage other identity providers, which can be a help for forgetful app users.

The example given by Descope was a user who signed up for app access using Facebook, and later became inactive, forgetting the identity provider that was used.  If they then use "Log in with Microsoft" for that same app, then the two provider accounts may be merged for the purpose of accessing the app. However, if an e-mail claim was permitted by the application developer, then that's when an attacker could substitute its own e-mail claim.

The problem with Azure AD is that it had allowed this e-mail claim to be changed by an attacker, thereby giving the attacker "full control over the user account." That scenario was the basic problem, Descope indicated.

"In Microsoft Azure AD, the email claim is both mutable and unverified so it should never be trusted or used as an identifier," the security researchers wrote.

Descope reported the Azure AD issue to Microsoft on April 11, 2023, and subsequently received a $75,000 bug bounty. Microsoft has since issued guidance to application developers with vulnerable apps. Microsoft also added "mitigations to protect customers from some applications that may be vulnerable."

Here's how Microsoft's announcement expressed it:

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.

Microsoft also offered succinct guidance to application developers:

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.

In perhaps a related post, Microsoft identity and standards expert Pamela Dingle explained that OpenID Connect is supposed to work using the sub (subject) attribute as a claim, and the "use of claims other than subject identifier to uniquely identify an end user in OpenID Connect is non-compliant."