Cybercriminals are using previously unknown methods to initiate URL redirection attacks, which leverage OAuth 2.0 implementations by Microsoft and other companies.
The OAuth 2.0 open standard authorization protocol is utilized by third-party cloud applications in order to gain limited access to users’ resources across various platforms, including Microsoft 365 or Google Workspace. Starting in February 2020, attackers have leveraged what Proofpoint researchers describe as "vulberabilities," which occur “by design” in OAuth 2.0 implementations by certain providers, such as Microsoft and GitHub. The attackers tie these errors into their phishing attacks, which aim to stealthily steal recipients' Outlook Web Access, PayPal login credentials and credit card details.
This attack puts a unique spin on the classic open redirection attack that has been widely used by cybercriminals, where attackers craft URLs for web applications that cause a redirection to an arbitrary external domain.
“Classic open redirection attacks will hold the redirection target in the URL itself,” said David Krispin and Nir Swartz, security researchers with Proofpoint, on Wednesday. “In the new flavor we discovered, the redirection target URL is configured in the OAuth provider’s framework, without any validation of this URL.”
Researchers said that campaigns utilizing this new tactic have successfully targeted hundreds, “and the numbers grow daily.”
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.
Phishing Attacks Abusing OAuth Implementations
In a real-life attack, researchers observed a PayPal phishing email leveraging the login.live.com “Microsoft Accounts” login system (of note, this login system is legitimate and does not collect credentials as part of the phishing attack). The Microsoft 365 application authorization URL, sent to targets via phishing emails, prompted them to sign in to their Microsoft accounts. This URL contained the client_id and scope parameters, but the response_type parameter was missing. When users entered their Microsoft 365 credentials and clicked “Next,” they were redirected to a phishing page due to the invalid parameter. To the victim, this attacker-controlled URL looked like a PayPal login page.
Researchers also observed variations of this attack that stem from tweaking other parameters in the authorization URL. For instance, another attack included an invalid value for the scope parameter that led to users being redirected by Microsoft after authentication. Other providers, such as GitHub, also contained multiple similar “error scenarios” where they redirect users to malicious URLs.
Researchers said this attack is particularly stealthy because the redirection target URL is missing from the legitimate URL, allowing attackers to bypass most phishing detection tools. Most of the URLs utilized are also abusing Microsoft’s Azure domains to host phishing attacks, which make them look more legitimate, said researchers.
“The victim who clicks on the URL trusts the OAuth provider and doesn’t expect an immediate redirection, as we observed in this type of attack,” said researchers. “This makes the attack sequence more covert and potent compared to classic open redirection attacks.”
Possible Mitigations
Tim Choi, vice president of product marketing with Proofpoint, said that OAuth implementations from other providers, like Google or LinkedIn, demonstrate “better ways of error handling” to keep the OAuth framework more secure. Google’s implementation of OAuth handles errors inside its domain with special Google error pages. Researchers said they could not find similar OAuth redirection attacks for this implementation. However, several redirection flows remain that can land users on a phishing page. For instance, the registration of a sign-in OAuth application with malicious redirect URLs in Google’s framework requires no verification by Google.
Researchers said one potential solution for this design error would be to redirect users to provider domains with “a detailed explanation of the error,” or taking on several precautions when forwarding the user to the developer’s redirect URL.
“Effective mitigation techniques are presenting the user with a clear warning that they’re leaving the current application, implementing a long delay before automatic redirection of the user or forcing the user to click on the link before the redirection,” they said.