Phishing Attacks Abuse Microsoft OAuth Implementations

0Auth 2.0 Authorization Code Flows

The OAuth 2.0 authorization protocol requires developers to register their applications within the OAuth provider’s framework in order to receive a unique application ID. As part of this process, developers provide their redirect URI, so the provider can redirect the user with the authorization response to the redirect URI. The OAuth 2.0 flow, meanwhile, is made up of authorization code flows, implicit flows and hybrid flows, which combines the authorization code and implicit flows.

“The relevant OAuth flows begin with a user browsing to (or being redirected to) the authorization URL, which is located at the /authorize endpoint under the right API URL,” said researchers.

These URLs require client_id and response_type parameters (OAuth 2.0 also requires the scope parameter). It is here that the issue exists: If URLs from third-party applications are missing a response_type query parameter, unsuspecting users that click the link can be redirected to phishing landing page URLs, said researchers. In an array of phishing attacks, researchers observed application URLs with missing response_type parameters or with non-relevant values in these parameters (which is anything other than the relevant values like “token,” “code” or “id_token”).

In order to abuse this implementation, attackers would first need to register their malicious app in the OAuth provider’s framework, with a redirection URL that points to a phishing site. Then, the attacker would send an email to their target with a URL for OAuth authorization. The URL is legitimate looking because it is hosted on a Microsoft domain – however, because the attacker modified the query parameters in the URL, it introduces an error and triggers a redirection attack.