Pierluigi Paganini December 03, 2019

A vulnerability in the Microsoft OAuth implementation exposes Azure cloud accounts to takeover.

The vulnerability affects the way Microsoft applications use OAuth for authentication, these applications trust certain third-party domains and sub-domains that are not registered by Microsoft.

Experts from Cyberark discovered the following three vulnerable Microsoft applications that trust these unregistered domains Portfolios, O365 Secure Score, Microsoft Service Trust.

“This vulnerability’s attack surface is very wide and its impact can be very powerful.” reads the analysis published by CyberArk “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 the OAuth authorization flow implemented by Microsoft, a Microsoft application user can request access from a whitelisted URL approved by Microsoft to login.

The owner of the third-party website or application will receive a token with specific permissions that allows it to act on behalf of the owner of the token.

The experts noticed that some URLs whitelisted by Microsoft are not previously registered with the Azure portal. The researchers noticed that the web API URLs that are “trusted” by Microsoft native apps end with “.cloudapp.net,” “.azurewebsites.net” and .{vm_region}.cloudapp.azure.com, but they noticed that at least 54 sub-domains with these characteristics were not registered in the Azure portal.

The attackers could take over these domains and then registering them, in this way they would be approved by default and could request users’  “access_tokens” and act on behalf of the user with its permissions.

“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.” continues the analysis.
“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.”

The experts published a proof of concept (PoC) of the attack that shows how an attacker could create a crafted link for the Microsoft OAuth authentication process. The researchers composed the link using three parameters: The application_id parameter that must match the vulnerable OAuth application, the redirect_uri parameter that must be white-listed domains, and the resource parameter that must be the desired resource that an attacker wants to get access to on behalf of the user.

An attacker could embed an iframe tag into a website with the “src” attribute set to the crafted link, then trick the victim into visiting it. Once the victim visits the website, the victim’s browser will render the iframe and microsoftonline[.]com redirects the victim to the attacker’s domain and automatically grants the access token.

The attackers install in the domain a Javascript that sends API requests using the stolen access token.

Below the vulnerability 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

“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.” concludes the report.

“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.”

Pierluigi Paganini

(SecurityAffairs – OAuth, hacking)

[adrotate banner=”5″]

[adrotate banner=”13″]