Vulnerabilities

Microsoft Patches Vulnerability Leading to Azure Account Takeover

Microsoft recently addressed an OAuth 2.0 vulnerability that could allow an attacker to take over Azure accounts.

The issue impacts specific Microsoft OAuth 2.0 applications and allows an attacker to create tokens with the victim’s permissions, CyberArk’s security researchers have discovered.

<p><strong><span><span>Microsoft recently addressed an OAuth 2.0 vulnerability that could allow an attacker to take over Azure accounts.</span></span></strong></p><p><span><span>The issue impacts specific Microsoft OAuth 2.0 applications and allows an attacker to create tokens with the victim’s permissions, CyberArk’s security researchers have discovered.</span></span></p>

Microsoft recently addressed an OAuth 2.0 vulnerability that could allow an attacker to take over Azure accounts.

The issue impacts specific Microsoft OAuth 2.0 applications and allows an attacker to create tokens with the victim’s permissions, CyberArk’s security researchers have discovered.

The root cause of the security flaw, which CyberArk calls BlackDirect, is that anyone can register domains and sub-domains that OAuth applications trust.

Moreover, because the apps are approved by default and can ask for an “access_token,” an attacker could gain access to Azure resources, AD resources and more.

The OAuth protocol allows end users to grant applications access to information from other apps or websites, without revealing secrets or passwords. OAuth2 also allows third-party apps to grant limited access to an HTTP service, when the client — be it website or mobile application — requests it.

The OAuth 2.0 Authorization Request could be implemented using “redirect_uri” for passing the token to the application handler. Equivalent to “redirect_uri” is “ReplyUrls,” a list of trusted URLs that the application uses to determine the URLs and hosts that can get the tokens generated for the application.

A misconfiguration of redirect_uri could involve whitelisting a non-existent domain, which provides an attacker with the possibility of stealing access tokens by passing the token to overtaken domains or sub-domains.

Some of the Azure applications published by Microsoft itself (Portfolios, Office 365 Secure Score, and Microsoft Service Trust) were found vulnerable to this attack: an adversary taking over domains and URLs that Microsoft trusts could get access tokens that have the victim’s permissions.

Advertisement. Scroll to continue reading.

“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,” the security researchers say.

Because these Azure applications are automatically approved within a Microsoft account, no user consent is required for the attackers to exploit them to generate tokens. On top of that, these apps cannot be removed from the Microsoft Accounts approved applications portal (some don’t even appear there).

One scenario in which the vulnerability could be exploited involves attackers gaining access tokens and perform requests to API endpoints, such as resetting passwords for other users in AD, adding members to a directory role, and adding users to groups.

“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,” CyberArk says.

The security researchers detail both zero-click and one-click attack vectors for this vulnerability. Sensitive data could be stolen or lost and servers could be compromised even if the victim does nothing more than visiting a website.

The issue was reported to Microsoft in late October and a fix was released a couple of weeks ago.

Related: Microsoft Unveils New Security Tools for Azure

Related: New Azure AD Feature Detects Unauthorized Access Attempts

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version