Microsoft and Google OAuth flaws can be misused in phishing attacks


Researchers have discovered a set of previously unknown methods to launch URL redirect attacks against weak OAuth 2.0 implementations.

These attacks can lead to bypassing phishing detection and email security solutions, and at the same time, give phishing URLs false legitimacy for the victims.

Relevant campaigns have been detected by Proofpoint and target Outlook Web Access, PayPal, Microsoft 365 and Google Workspace.

How the attack works

OAuth 2.0 is a widely adopted authorization protocol that allows a web or desktop application to access resources controlled by the end user, such as their email, contacts, profile information, or social accounts.

This authentication feature relies on the user granting access to a particular application, which creates an access token that other sites can use to access a user’s resources.

When developing OAuth applications, developers are free to choose from different types of feeds available, depending on their needs, as shown below.

Microsoft's OAuth flow
Microsoft’s OAuth flow
Source: proof

These flows require application developers to set specific parameters, such as a unique client ID, scope, and redirect URL is opened after successful authentication.

However, Proofpoint discovered that attackers could change some of the settings in valid authorization flows, triggering a victim redirect to an attacker-provided site or a redirect URL in a registered malicious OAuth application.

Since this happens after the victim clicks on a legitimate looking URL that is owned by Microsoft, the victim mistakenly assumes that the URL is legitimate even if it is redirected to a malicious site.

This redirect can be triggered by modifying the ‘response_type’ request parameter to contain an invalid value, and the victim is redirected to a Microsoft phishing page after authentication.

The same happens if the ‘scope’ parameter is changed to trigger an “invalid_resource” error.

Authentication flow settings
Authentication flow settings
Source: proof

“The attacks use dozens of separate Microsoft 365 third-party applications with malicious redirect URLs defined for them,” explains Proofpoint Report

“All third-party apps were delivered through a Microsoft URL with a missing response_type request parameter, with the intention of redirecting unsuspecting users to different phishing URLs.”

Microsoft consent screen during authentication
Microsoft consent screen during authentication
Source: proof

The third attack scenario is that the user clicks the Cancel button on the consent screen, which triggers a redirect to the malicious app’s URL.

Proofpoint explains that triggering the redirect even before authentication is also possible, depending on the selected OAuth flow, which is the case with Azure Portal.

By using OAuth URLs that have been altered to produce errors in the authentication flow, phishing campaigns can present legitimate-looking URLs that ultimately redirect to landing pages that attempt to steal login credentials.

These attacks are not theoretical, as Proofpoint has seen examples in nature of malicious actors abusing this bug to redirect users to phishing landing pages.

“We analyzed data from Proofpoint and found large-scale targeted attacks using modi operandi (MO), which we will discuss in detail later in this blog post. The attacks use dozens of different methods. Microsoft 365 third-party apps with malicious redirect URLs defined for them.

“They have successfully targeted hundreds of users of Proofpoint tenant customers, and their numbers keep growing every day,” said Proofpoint researchers David Krispin and Nir Swartz.

An extended problem

Other OAuth providers are affected by similar bugs that make it easier to create trusted URLs that redirect to malicious sites.

For example, GitHub allows anyone to register an OAuth app, including malicious actors who build apps whose redirect URLs lead to phishing landing pages.

Threat actors can then create OAuth URLs that contain legitimate-looking redirect URLs, which GitHub ignores and uses app-defined redirect instead. To the user, however, the URL looks legitimate and will look trustworthy to click on.

Google makes it even easier because a malicious actor can register a login OAuth app and set a “redirect_uri” parameter on a malicious URL, bringing the victim there right after authentication.

Google doesn’t verify this URL, so it could be anything from a phishing page to a malware removal site.

Set a malicious redirect-uri parameter
Setting a malicious redirect-uri parameter
Source: proof

Possible solutions

Proofpoint’s report provides several techniques to mitigate these bugs, the most effective being not to ignore invalid parameters and instead display an error page.

Also, implementing a long delay before the automatic redirect or introducing an extra click for the redirect to take place would prevent many people from getting phished.

“Phishing of innocent users remains the most effective attack method to compromise user credentials and violate your organization’s network in the process. Email protection systems are powerless against these attacks, ”concludes Proofpoint.

“By abusing the OAuth infrastructure, these attacks send malicious emails to their targets undetected. Such attacks on PayPal can result in the theft of financial information such as credit cards. Phishing attacks against Microsoft can lead to fraud, intellectual property theft, and more.

The Internet Engineering Task Force (IETF) provides safety recommendations for those who implement OAuth authentication servers.


Comments are closed.