Microsoft OAuth Flaw Opens Azure Accounts to Takeover

microsoft OAuth cloud takeover

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

A vulnerability in the way Microsoft applications use OAuth for third-party authentication could allow an attacker to take over Azure cloud accounts.

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 apps they don’t need to re-enter their passwords every time.

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, researcher with CyberArk, in a Monday analysis of the flaw. “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.”

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, Tsarfati told Threatpost.

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

Then, the attacker could embed an iframe tag into a website with the “src” attribute set to the crafted link. Once the victim browses the website (lured in via simple social engineering tactics), the victim’s browser renders the iframe and microsoftonline[.]com redirects the victim to the attacker’s domain and automatically grants the access token. The Javascript running in the domain then sends API requests with the stolen access token.

The vulnerability was discovered Oct. 29 and fixed Nov. 19. Researchers publicly disclosed the flaw on Monday. While a patch exists, researchers said that users can also mitigate OAuth risks overall by making sure that all trusted redirect URIs configured in the app are under their ownership, as well as removing unnecessary redirect URIs and disabling non-used applications.

“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,” said researchers.

Tsarfati told Threatpost that Microsoft didn’t issue a CVE because the bug is located only in their Online Service.

“We resolved the issue with the applications mentioned in this report in November and customers remain protected,” a Microsoft spokesperson told Threatpost.

Free Threatpost Webinar: Risk around third-party vendors is real and can lead to data disasters. We rely on third-party vendors, but that doesn’t mean forfeiting security. Join us on Dec. 18th at 2 pm EST as Threatpost looks at managing third-party relationship risks with industry experts Dr. Larry Ponemon, of Ponemon Institute; Harlan Carvey, with Digital Guardian and Flashpoint’s Lance James. Click here to register.

Suggested articles

biggest headlines 2020

The 5 Most-Wanted Threatpost Stories of 2020

A look back at what was hot with readers — offering a snapshot of the security stories that were most top-of-mind for security professionals and consumers throughout the year.