Azure AD 'Log in With Microsoft' Authentication Bypass Affects Thousands

Organizations that have implemented the “Log in with Microsoft” feature in their Microsoft Azure Active Directory environments could potentially be vulnerable to an authentication bypass that opens the door to online and cloud account takeovers.

According to researchers at Descope, who dubbed the attack “nOAuth,” the issue is an authentication implementation flaw that affects multitenant OAuth applications in Azure AD, Microsoft’s cloud-based identity and access management service. A successful attack gives a bad actor full run of a victim’s accounts, with the ability to establish persistence, exfiltrate data, explore if lateral movement is possible, and so on.

“OAuth and OpenID Connect are open, popular standards which millions of Web properties already use,” says Omer Cohen, CISO at Descope. “If ‘Log in with Microsoft’ is improperly implemented, several of these apps could be vulnerable to account takeover. Small businesses with fewer developer resources could especially be impacted.”

Inside the nOAuth Cyberattack Threat

By way of background, OAuth is an open, token-based authorization framework that allows users to log into applications automatically, based on previous authentication to another trusted app. This is familiar to most people from the “Log in with Facebook” or “Log in with Google” options available on many e-commerce websites.

In the Azure AD environment, OAuth is used to help manage user access to external resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications using OAuth apps.

“Azure Active Directory also manages internal resources like apps on your corporate intranet and any cloud apps developed by your own organization by providing authentications via OAuth, OIDC, and other standard protocols,” according to the Descope analysis. In other words, it holds the keys to a lot of important corporate data.

The weakness allows bad actors to perform cross-platform spoofing simply by using an unwitting victim’s email address to impersonate them, according to Descope’s analysis on the issue, released this week.

“In usual OAuth and OpenID Connect implementations, the user’s email address is used as the unique identifier by applications,” explained researchers at Descope. “However, in Microsoft Azure AD, the ‘email’ claim returned is mutable and unverified, so it cannot be trusted.”

That means that anyone with malicious intent and a decent amount of platform knowledge can simply set up an Azure AD account, and arbitrarily change the email attribute under “Contact Information” in that account to control the email authentication claim.

"[This] allows the attacker to use ‘Log in with Microsoft’ with the email address of any victim they want to impersonate," the researchers explained. “They can take over victims’ accounts on any app that uses ‘email’ claim as the unique identifier for Microsoft OAuth and does not validate that email address, completely bypassing authentication.”

The attack flow is unnervingly simple:

1. The attackers accesses their Azure AD account as an administrator.
2. The attackers change the “email” attribute of their account used for authentication to the victim’s email address.
3. Since Microsoft does not require the email change to be validated on Azure AD, the system merges the two accounts and gives the attackers access to the victim’s environment.

A Far-Ranging Authentication Weakness

To better understand the scope of the problem, the Descope researchers created a nOAuth proof-of-concept (PoC) exploit and tested it “with a white-hat attack on hundreds of websites and applications to check if any of them were vulnerable,” they said. “We found that quite a few of them were.”

Amid the sitting ducks were a design app with millions of monthly users, a publicly traded customer experience company, a leading multicloud consulting provider, as well as several SMBs and early-stage startups.

“We also informed two authentication platform providers that were merging user accounts when ‘Log in with Microsoft’ was used on an existing user account,” according to the report. “In this instance, merging the attacker account with a legitimate user account would hand full control over the user account to the attacker. As a result, all of their customers using ‘Log in with Microsoft’ would have been vulnerable.”

These findings, according to the researchers, “are a drop in the ocean of the Internet,” and there are likely many, many thousands of other users that could be affected.

Microsoft has always issued general guidance to users to not to use an email address as a unique identifier for authentication, but after Descope informed Microsoft of the breadth of the issue, the computing giant has revamped its Azure AD OAuth implementation guidance to include two new claims to use, and dedicated sections on claim verification.

“If your app uses ‘Log in with Microsoft’ and you handle authentication in-house, it’s critical that you check if you use the email claim returned by Azure AD as the unique identifier,” Cohen notes. “If so, remediation steps should be taken to ensure the claim used as the unique identifier for the user is the ‘sub’ (Subject) claim to avoid potential exploitation.”

Incorrect OAuth Implementations Plague Businesses

Incorrect implementations of OAuth have been coming to light at big businesses lately, showcasing a need for organizations to lock down this potentially damaging attack vector.

In March, for instance, flaws in the authorization system of the Booking.com website came to light that could have allowed attackers to take over user accounts and gain full visibility into their personal or payment-card data, as well as log in to accounts on the website’s sister platform, Kayak.com.

And in May, a bug tracked as CVE-2023-28131 was found in the OAuth implementation of Expo, an open source framework for developing native mobile apps for iOS, Android, and other Web platforms using a single codebase. The flaw threatened the accounts of any users that used various and social media accounts to log in to an online service that uses the framework.

Cohen underscores that the OAuth standard and others like it are trustworthy and strong authentication approaches but that businesses need to make sure to work with cybersecurity and authentication experts when building them in.

“These standards are extremely complicated to work with,” he says. “Authentication isn’t something you can just add on and check a box. Implementing these standards correctly is critical to the security of the application.”

He adds, “If businesses chose to implement these standards in-house, then they must have regular pen testing and review of the implementation, or they can use an authentication platform that is built by security experts.”

He stresses that the importance of this can’t be understated, given that cybercriminals are actively looking for these types of weaknesses.

“These are very typical attack vectors exploited,” Cohen notes. “Attackers use these to cause widespread harm.”

He adds, “With the increase of organizations adopting cloud technologies and SaaS applications, identity is the new firewall. If user authentication is not well-designed, it doesn’t matter how secure the application is itself as you will leave the front door open to cyberattacks.”