BlackDirect: Microsoft Azure Account Takeover

Over the last few weeks, my team and I have been working on research associated with Microsoft Azure and Microsoft OAuth 2.0.  Over the course of that time, we found a vulnerability that allows for the takeover of Microsoft Azure Accounts.  Affecting specific Microsoft’s OAuth 2.0 applications, this particular vulnerability allows the creation of tokens with the victim’s permissions. This could let a malicious attacker access and control a victim’s account and take actions on their behalf.

TL;DR

The OAuth applications trust domains and sub-domains that are not registered by Microsoft can be registered by anyone (including an attacker).  These apps are approved by default and are allowed to ask for “access_token.” The combination of these two factors makes it possible to produce an action with the user’s permissions – including gaining access to Azure resources, AD resources and more.

As part of our research, we developed a free and automatic scan for everyone to be able to discover similar vulnerable applications in their Azure environment.

The scan is available from the website:

https://black.direct/

In addition, the website includes more details on the BlackDirect finding.

What is OAuth?

OAuth is a protocol for authorization that is commonly used as a way for end users to grant websites or applications access to their information from other websites without giving the website or app secrets or passwords.  It is widely used by many companies to permit users to share information and data about their accounts with third party applications or websites.

The next-generation of the OAuth protocol – OAuth2 – allows third-party applications to grant limited access to an HTTP service, either on behalf of a resource owner or by allowing the third-party application to obtain access on its behalf. Access is requested by a client, which can be a website or a mobile application.

The protocol itself is well built and secured, but a wrong implementation or inappropriate usage and configuration can have a colossal impact.  During the authorization process, the third-party company or application gets a token with specific permissions to take actions on behalf of the user to whom the token belongs.  To put this in perspective, highly privileged OAuth2 tokens, in most cases, equate to having the username and password for the account itself.  In addition, if a malicious user or attacker steals such a token, it will, in some cases, allow the attacker to bypass security components like 2FA.

When we talk about tokens, there are two main types to keep in mind.   A permanent token known as a “Refresh Token” and a temporary one known as an “Access Token“.  The refresh token is used to validate identification and obtain an access token.

BlackDirect Vulnerability

One of the ways to implement OAuth 2.0 “Authorization Request,” according to the RFC, is by passing the token to the application handler using “redirect_uri”, which describes the destination (specific URLs) where the generated OAuth tokens are passed.

“ReplyUrls” is a white-list of trusted URLs that are set to an application to determine which URLs and hosts can get the tokens generated for the application.  In other words, “ReplyUrls” is equivalent to “redirect_uri”.  You can see that configuration panel in Figure 1.

One of the possible attacks that affect OAuth applications is a misconfiguration of redirect_uri. White-listing a non-existent domain allows attackers to steal an application user’s access tokens by passing the token to overtaken domains / sub-domains.  As a privileged credential, it can be dangerous and impactful if the obtained access token is stolen.

Through our research,  we found a couple of Azure applications published by Microsoft (also known as First-Party Applications) that are vulnerable to this type of attack.  If an attacker gains control of the domains and URLs Microsoft trusts, Microsoft’s published applications makes it possible for the attacker to lead victims to automatically generate access tokens with their permissions.  All the attacker has to do is get their victims to click on a link or visit a compromised website, which can be done easily with simple social engineering techniques.

These applications are more valuable than others because they are automatically approved within any Microsoft account and, therefore, don’t require any user consent in order for attackers to exploit them to generate tokens. It is also impossible to remove these applications from Microsoft Account’s approved applications portal and some don’t even appear at all in the portal.

Taking over the URLs
I listed all the service principals in my account using the “Get-AzureADServicePrincipal” command.

Looking at the URLs allowed in Microsoft’s Applications, I noticed that some of the URLs end with “.cloudapp.net”, “.azurewebsites.net” and .{vm_region}.cloudapp.azure.com,” which can all be registered via the Azure portal.
To make sure no real attackers could exploit this vulnerability, I registered every sub-domain that wasn’t already registered – 54 of them (in Figure 2).  That being said, there may be more sub-domains that aren’t listed.

The vulnerable apps that we found are:

• Portfolios
• O365 Secure Score
• Microsoft Service Trust

Combining the Two
In this section, I will describe how taking-over the whitelisted URLs allowed us to force the users into unconsciously giving us an “access_token” to their account by visiting a specially crafted link, which then initiated the OAuth flow.

To initiate the Web OAuth authentication flow, you need to browse a link similar to the following: https://login.microsoftonline.com/common/oauth2/authorize?response_type=token&client_id={CLIENT_ID}&resource={RESOURCE}&redirect_uri={REDIRECT_URI}

To exploit the vulnerability, we have to set the parameters to match the vulnerable OAuth application, including the desired resource for which the token is valid.
The “client_id” is the application id, the “resource” is the audience that the token will be valid for and the “redirect_uri“ is the domains / URI that the token will be passed to.

This OAuth vulnerability could be very dangerous. Take, for example, the following scenario:

Attackers requesting a token on behalf of a privileged user for “https://graph.windows.net” with “user_impersonation” privileges – default privileges every application gets, if not defined otherwise – can perform requests to API  endpoints, including resetting passwords for other users in the AD, adding members to a directory role or adding users to groups (depending on the victim’s privileges).  You can see more API calls documented here.
This vulnerability makes it much easier to compromise privilege users – whether through simple social engineering techniques or by infecting a website that the privileged users occasionally access. Regardless, the result would most likely entail the full compromise of the entire domain and the organization’s Azure environment.

Attack Vectors

Zero-Click:

1. The attacker creates a crafted link for Microsoft OAuth Web flow and:
   1. Sets the application_id parameter to match the vulnerable OAuth application.
   2. Sets the redirect_uri parameter to the controlled, white-listed domains.
   3. Sets the resource parameter to the desired resource that he wants to get access to on behalf of the user.
2. The attacker embeds an iframe in a website with the “src” attribute set to the crafted link.
3. The victim browses the website. The victim’s browser renders the iframe and microsoftonline.com redirects him to the attacker’s domain with the access token.
4. The Javascript running in the domain sends API requests with the stolen access token.

One-Click:

1. The attacker creates a crafted link for Microsoft OAuth Web flow with the vulnerable Microsoft applications and:
   1. Sets the application_id to match the vulnerable OAuth application.
   2. Sets the redirect_uri param to the controlled white-listed domains.
   3. Changes the resource to the one he wants to get access to on behalf of the user.
2. A victim clicks on the crafted link and microsoftonline.com redirects him to the attacker’s domain with the access token.
3. The Javascript running in the domain sends API requests with the stolen access token

POC

 Mitigating The Threat

While OAuth 2.0 is an excellent solution for authorization, if misused or misconfigured, it could have a tremendous impact, allowing for over-privileged third-party applications or the eventual account takeover by malicious attackers.

To mitigate risk and prevent these vulnerabilities, you can do the following:

1. Make sure that all the trusted redirect URIs configured in the application are under your ownership.
2. Remove unnecessary redirect URIs.
3. Make sure the permissions that the OAuth application asks for are the least privileged one it needs.
4. Disable non-used applications.

This vulnerability’s attack surface is very wide and its impact can be very powerful. By doing nothing more than clicking or visiting a website, the victim can experience the theft of sensitive data, compromised production servers, lost data, manipulation of data, encryption of all the organization’s data with ransomware and more.

In this case, there’s not much a user can do – Microsoft has to issue a fix (which they have.)  That being said, solutions like CyberArk’s Privileged Session Manager can help lower the impact of vulnerabilities like this by preventing attackers from stealing privileged tokens.

Disclosure Timeline

29/10/19 – The vulnerability found

30/10/19 – Vulnerability reported to Microsoft

31/10/19 – Report was closed by Microsoft – ?!?

07/11/19 – Vulnerability reported again to Microsoft

08/11/19 – Case opened

12/11/19 – Microsoft contacted me for more information

20/11/19 – Vulnerability fixed