Some Microsoft applications are vulnerable to an authentication issue that could lead to Azure account takeover.

Vulnerability: The way in which the Microsoft applications use OAuth for third-party authentication could allow an attacker to take over Azure cloud accounts.

The vulnerability exists because when Microsoft applications undergo the OAuth 2.0 (the next generation of OAuth) authorization flow, they trust certain third-party domains and sub-domains that are not registered by Microsoft. CyberArk researchers discovered three vulnerable Microsoft applications that trust these unregistered domains: Portfolios (a portfolio management tool), O365 Secure Score (a security analytics tool) and Microsoft Trust Service (a portal providing resources about Microsoft security, privacy and compliance practices). “This vulnerability’s attack surface is very wide and its impact can be very powerful,” said Omer Tsarfati, a researcher with 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.”

What is OAuth?

OAuth is a protocol that allows app users to share data about their accounts with third-party websites or apps, so that when they sign into the applications, they don’t need to re-enter their passwords every time.

OAuth Authentication:

During a typical OAuth authorization flow, a user from a website or a mobile app can request access from third-party apps in order to log in. In Microsoft’s case, this user would be a Microsoft application user, and the third-party would be a whitelisted URL approved by Microsoft. The owner of the third-party website or application then 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,” researchers said.

The problem is, some of Microsoft’s white-listed URLs are not previously registered in the Azure portal. Looking at the web API URLs that are “trusted” by Microsoft native apps, Tsarfati noticed that some URLs end with with “.cloudapp.net,” “.azurewebsites.net” and .{vm_region}.cloudapp.azure.com.” And, Tsarfati noticed that at least 54 sub-domains with these URL endings were not registered in the Azure portal – plus, there may be more that weren’t discovered, he said.

Attackers can take advantage of this by taking over these domains and then registering them, meaning that they would be approved by default and could request users’  “access_tokens,” which would then allow them to take actions using users’ permissions. If a victim is an Azure admin, for instance, an attacker could access high-level permissions, like adding unwanted members to a Microsoft Active Directory role, resetting other users’ passwords or adding users to groups,

Remediation:

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

• Make sure that all the trusted redirect URIs configured in the application is under your ownership.
• Remove unnecessary redirect URIs.
• Make sure the permissions that the OAuth application asks for are the least privileged ones it needs.
• Disable non-used applications.