Researchers Discover Microsoft Azure Account Takeover Vulnerability

• The Cyberark team has discovered a severe flaw in specific Microsoft OAuth 2.0 applications.
• An attacker could steal the access tokens of the victim, and this would open up the way to numerous ways of exploitation.
• Microsoft has issued a fix, but administrators need to be careful with how they configure their OAuth implementation.

Researchers from Cyberark have discovered a vulnerability that enables attackers to take over Microsoft Azure Accounts. They have named the flaw “Black Direct”, and it is based on the wrongful permission to allow a hacker to steal or create tokens that belong to the legitimate users. The implications of this would be the accessing of the target's account by a third party, and the ability to take unlimited actions on their behalf. The team clarifies that the discovered flaw affects specific Microsoft OAuth 2.0 applications which are the ‘Portfolios’, ‘O365 Secure Score’, and ‘Microsoft Service Trust’.

The main issue lies in the trusting mechanism that underpins OAuth applications, and the fact that they are set to trust domains and sub-domains which are not registered by Microsoft. These domains can be registered by someone with malicious intents, so when the apps ask for an access token they are automatically provided with it. OAuth is an authorization protocol that is widely used for the purpose of information sharing and exchange permissions. For example, a website may ask us to permit an app to access our account, or a third party app may ask a website for user data as input. OAuth 2.0 grants limited access to an HTTP service, and in order not to request permission every time, various categories of access tokens are generated once and used by then.

If the admin maintains a “trusted URLs” configuration containing domains that aren’t under their ownership, an attacker would be given the chance to steal the access token by passing it to that domain, after registering it of course. The attacker also needs to set the “application_id” parameter to match one of the vulnerable app, while the “redirect_uri” parameter needs to point to the malicious and white-listed domains too.

Source: Cyberark

To prevent all this from happening to you, ensure that the redirect URIs are under your ownership and remove any that don’t need to be there. Also, disable any applications that aren’t used and review the list of permissions that are requested from what’s left. If possible, limit the privileges to the lowest level that still does the job. The Cyberark team discovered the flaw on October 29, 2019, but Microsoft didn’t realize the essence of the report immediately. This is why the fix took them quite a while, finally taking place on November 20, 2019.

Do you have anything to comment on the above? Let us know of your thoughts in the section down below, or on our socials, on Facebook and Twitter.