Microsoft Azure AD flaw can lead to account takeover

Researchers have found that a flaw in Microsoft Azure AD can be used by attackers to take over accounts that rely on pre-established trust.

In a nutshell, Microsoft Azure AD allows you to change the email address associated with an account without verification of whether you are in control of that email address. And in Microsoft Azure AD OAuth applications that email address can be used as a unique identifier.

So, how can this be used in an account take-over?

To understand how this flaw—dubbed nOAuth by the researchers—works we need to take a few steps back and explain how OAuth works.

OAuth (short for Open Authorization) is a standard authorization protocol. It allows us to get access to protected data from an application. Generally, the OAuth protocol provides a way for resource owners to provide a client, or application with secure delegated access to server resources. It specifies a process for resource owners to authorize third-party access to their server resources without providing credentials.

Chances are you have dealt with OAuth many times without being aware what it is and how it works. For example, some sites allow you to log in using your Facebook credentials. The same reasoning that is true for using the same password for every site is true for using your Facebook credentials to login at other sites. We wouldn’t recommend it because if anyone gets hold of the one password that controls them all, you’re in even bigger trouble than you would be if only one site’s password is compromised.

In the example we used above, Facebook is called the identity provider (IdP). Other well-known IdPs are Google, Twitter, Okta, and Microsoft Azure AD. For the “Open” concept in OAuth to work, the authentication is based on pre-established trust with the IdP. In our example, because you are logged into Facebook, the other site or service accepts your identity and allows you access.

Azure AD manages user access to external resources, such as Microsoft 365, the Azure portal, and thousands of other software as a service (SaaS) applications using OAuth apps. The difference is that most IdPs advise against using an email-address as an identifier, but Microsoft Azure AD accepts it.

The attacker that wishes to abuse this flaw needs to set up an Azure AD account as admin. They can do this using an email address which is under their control. When they are all set, they can change the Email attribute to one that belongs to the target. The main flaw here is that this requires no validation whatsoever.

Now, all the attacker has to do is open the site or service they wish to take over and choose the “Login with Microsoft” option. They will automatically get logged into the account associated with the provided email address. Which was the one that belongs to the victim and not to the actual operator.

From that point on they can make the necessary changes to either gain persistence, steal information, or completely take over the account. With any luck the victim will get a “you logged in from a new device” type of notice, but that’s the best case scenario.

There is one caveat for the attacker though. Not all sites and services use the email address as a unique identifier.

The researchers have informed Microsoft and other stakeholders of the issue and steps are being taken to thwart this type of account takeover.

Microsoft already had existing documentation informing developers not to use the “email” claim as a unique identifier in the access token, and after the disclosure it published a dedicated page on Claims Validation with all the information a developer needs to consider when implementing authentication.

The researchers say they tested their proof-of-concept on hundreds of websites and applications and found many of them vulnerable. They shared the PoC with each affected organization and informed them of the vulnerability. While most of the affected apps were quick to respond and fix the issue, the number of tested apps was just a drop in the ocean of the Internet.

So, if you are running a site or service that uses Azure AD as an IdP, please check that you do not accept the Email attribute, because the email claim is both mutable and unverified so it should never be trusted or used as an identifier.