Key Takeaways
- Vulnerabilities in Microsoft and others’ popular OAuth2.0 implementations lead to redirection attacks that bypass most phishing detection solutions and email security solutions.
- Proofpoint has observed large-scale attacks successfully targeting hundreds of users of Proofpoint customer tenants, and the numbers grow daily.
- Most of the phishing URLs were abusing Microsoft’s Azure domains to host the phishing attacks, making them look more legitimate.
- The detected campaigns include, among others, Outlook Web Access phishing, PayPal login phishing and credit card harvesting.
Overview
Proofpoint has discovered several new, previously unknown methods to initiate a URL redirection attack using Microsoft and others’ popular OAuth2.0 security implementations. Third-party cloud applications use OAuth 2.0 to obtain limited access to protected users’ resources in major platforms such as Microsoft 365 and Google Workspace. Proofpoint threat researchers started detecting these redirection attacks against Microsoft 365 environments in February 2020.
Open redirection vulnerabilities arise when a web application incorporates user-controllable parameters to specify a redirect link. An attacker can craft a URL for a web application that causes a redirection to an arbitrary external domain. Classic open redirection attacks will hold the redirection target in the URL itself. In the new flavor we discovered, the redirection target URL is configured in the OAuth provider’s framework, without any validation of this URL.
Also, the redirection target URL will be missing from the legitimate URL and will therefore bypass most phishing detection solutions and email security solutions. 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. This makes the attack sequence more covert and potent compared to classic open redirection attacks.
Real attacks targeting Microsoft’s OAuth implementation
We analyzed Proofpoint data and found large-scale targeted attacks using modi operandi (MOs), which we’ll discuss in detail later in this blog post. The attacks use dozens of distinct Microsoft 365 third-party applications with malicious redirect URLs defined for them. They’ve successfully targeted hundreds of users of Proofpoint customer tenants, and the numbers keep growing daily.
All the third-party applications were being delivered through a Microsoft URL with a missing response_type query parameter, with the intention to redirect unsuspecting users to different phishing URLs. Most of the phishing URLs were abusing Microsoft’s Azure domains to host the phishing attacks, making them look more legitimate. The phishing kit used in these attacks was covered in a deep dive by SeclarityIO here.
The detected campaigns include, among others, Outlook Web Access phishing, PayPal login phishing and credit card harvesting—and these campaigns are still alive and evolving.
One PayPal phishing campaign is abusing the login.live.com “Microsoft Accounts” login system that requires no authentication from the user before redirecting to the phishing page. The following GIF demonstrates the redirection after the user clicks the legitimate Microsoft URL link:
Figure 1. GIF demonstrating a PayPal phishing scam, where a user is redirected after clicking on a legitimate Microsoft URL link
How Microsoft implements OAuth 2.0
OAuth 2.0 is a widely adopted protocol for authorization. When developing an OAuth application, developers must register their applications in the OAuth provider’s framework to get a unique application (client) id, and as part of this process they provide their redirect URI. The OAuth provider redirects the user with the authorization response to the redirect URI.
There are many different OAuth 2.0 flows. A redirection attack requires one of the following flows: Authorization code flow, Implicit flow and the Hybrid flow, which combines both the Authorization and Implicit flows.
Microsoft’s implementation of OAuth 2.0 relies on the Microsoft identity platform endpoint (v2.0), or the older Azure AD endpoint, for authenticating users before the authorization process.
The following diagram explains a basic OAuth sign-in flow (aka OpenID Connect). But the general idea holds true for the OAuth authorization code flow, which is the main and most prevalent use case.
Figure 2. Typical OAuth sign-in flow
Later in this post, we’ll discuss login.live.com, which is another login system for Microsoft personal accounts that OAuth 2.0 uses.
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.
In the case of the Microsoft identity platform, the URL features the following format:
Figure 3. Microsoft identity platform OAuth flow URL format
And in case of the v1.0 Azure AD endpoint, the URL features this format:
Figure 4. URL endpoint format for the v1.0 Azure AD endpoint
Both URLs require the client_id and response_type parameters for a valid URL, while the v2.0 also requires the scope parameter. Other query parameters are optional.
Note that authorization endpoints under the URL https://login.windows.net automatically redirect to https://login.microsoftonline.com with all the provided query parameters. That means every valid and invalid flow mentioned in this post also applies to URLs that start with https://login.windows.net instead of https://login.microsoftonline.com.
At this point, users will need to authenticate themselves, and then authorize the application’s permissions.
The authorized permissions will allow the application access to the user’s resources. Once the user consents, the authorization server redirects the user to the application’s redirect URL.
Figure 5. Microsoft login screen, permissions required
How to break the valid flow
The normal chain of events of the OAuth protocol detailed above happens when all the required query parameters are present and hold a valid value. To trigger a redirection attack, the attacker modifies some parameters or eliminates others completely. Then, the user is redirected to an attacker-controlled redirect URL after clicking a legitimate-looking URL belonging to Microsoft and identifying itself through one of the Microsoft authentication endpoints.
Microsoft, by design, sends error responses to the application’s redirect URL so that the application has a chance to handle them. Together with the fact that specific values for certain query parameters can trigger an error right after authentication, Microsoft’s design choice makes a redirection attack possible. An attacker can thus craft a special URL using one of the mechanisms we’ll describe later in this post, and send that URL to potential victims through email or any other means of communication.
So, what are the error cases that cause a redirection to happen? We will present different MOs, each starting with a legitimate Microsoft-owned URL followed by a redirection by Microsoft itself to an attacker-controlled URL with minimal user interaction throughout the flow:
1. When the response_type query parameter is missing or contains a nonrelevant value (anything other than “token,” “code,” or “id_token” or a combination of the last two values), the user will be redirected by Microsoft right after authentication. The following diagram illustrates a URL clicked by a user, with the response_type parameter missing from the URL:
Figure 6. Missing response_type attack flow
2. When the scope parameter exists but contains an invalid value (any value that will trigger an “invalid_resource” error), the user will again be redirected by Microsoft after authentication. The official documentation states that this can be caused by any scope belonging to a “resource that is invalid because it does not exist, Azure AD can’t find it, or it’s not correctly configured.”
A simple example for an invalid scope value is a typo in the scope value. An attacker can craft bad scope with the intent to confuse the user with a real scope (like Openld, where instead of capital letter “I” there is a lower case “L”). The following diagram illustrates the scenario of an invalid scope being used in the URL:
Figure 7. Invalid scope attack flow
3. If all the query parameters are valid, and the user gets to the consent screen, clicking the “Cancel” button will also cause the user to be redirected to the attacker-controlled URL.
Figure 8. Microsoft permissions requested consent screen
The third case, albeit not an immediate redirection, poses a dangerous threat. In this situation, clicking on the “Accept” button will give the malicious application access to the user’s resources, while clicking on the “Cancel” button will redirect the user to the malicious redirect URL of the application. The latter scenario can lead to whole new set of threats—think of credential phishing, forcefully downloading a malicious file, or even chaining the redirection with another vulnerability to deliver a completely different threat.
Breaking a different Microsoft login system
Microsoft maintains a totally different login system for personal accounts, called “Microsoft accounts,” where users can consent to the same type of applications registered through the Azure Portal, using URLs of the following format:
Figure 9. Microsoft personal accounts OAuth URL
All the previously mentioned redirection MOs are also available under this login system. A substantial difference is that in the case of this URL format, the redirections happen even before the authentication process. This means that when using the previously mentioned methods for redirecting the innocent user along with this URL format, the user won’t even get a chance to login and the redirection, by Microsoft itself, will happen as soon as the user clicks the maliciously crafted URL.
Figure 10. Microsoft accounts attack flow
Breaking OAuth flow for different providers
Other OAuth providers also suffer from similar open redirection vulnerabilities. GitHub, a popular, git-based code hosting service, which is also owned by Microsoft, allows users to create OAuth applications that automate and improve workflows. Using GitHub as the identity provider to authenticate users against, anyone can register an OAuth application while supplying a redirect URL that might be a malicious phishing URL.
After registering your app and obtaining your client_id, there are multiple error scenarios in which GitHub, by design, will redirect users to the malicious redirect URL:
1. When the redirect_uri query parameter differs from the application-defined URL, users will be redirected (after authentication) to the redirect URL defined for the app. That means attackers can target users to click on consent URLs embedded with any legitimate URL to cause a redirection to a different malicious URL. The following URL will not redirect to the legitimate URL, but to the original URL registered for the app:
Figure 11. GitHub OAuth URL
2. If the user enters the consent page successfully but rejects access to the application (by clicking the “Cancel” button), they will also be redirected to the redirect URL. Although it’s a dangerous practice, the redirect URL is mentioned at the bottom of the consent page, with the text “Authorizing will redirect to: <redirect URL>.” Note that the text doesn’t mention that also canceling will redirect users to the redirect URL.
3. Even if the application with the malicious redirect URL is suspended by GitHub, users will still be redirected to the malicious URL.
Unlike Microsoft and GitHub, Google’s OAuth implementation is handling URL errors inside its domain with special Google error pages. Therefore, our researchers could not find similar OAuth redirection vulnerabilities. However, there are multiple non-erroneous redirection flows in which a user can be tricked into a phishing page:
1. Registering a sign-in OAuth application with a malicious redirect URL in Google’s framework requires no verification by Google. The following example URL will cause Google to redirect the user, right after authentication, to the malicious redirect URL (mentioned with the “redirect_uri” query parameter), with no additional consent screen popups:
Figure 12. Google OAuth URL
2. A more severe case of open redirection was found in the admin consent flow for marketplace applications. Any legitimate marketplace application can be used, and all that’s needed is the app’s identifier. With that identifier, a URL of the following format can be crafted:
Figure 13. Google Workspace OAuth URL
After an admin user clicks on the link and authenticates, the consent screen of that application will appear. If the admin clicks on the “Cancel” button, Google will redirect the admin to the malicious URL supplied, even though this URL doesn’t match the application’s defined redirect URL.
Effective mitigation techniques
Phishing is easier with covert redirection attacks that exploit OAuth implementation vulnerabilities and use legitimate Microsoft domains. These attacks can fool even the most tech-savvy users. Other OAuth providers’ implementations that we’ve observed, like Google or LinkedIn, show us that there are better ways of error handling to keep the OAuth framework more secure.
One way is to redirect the user to the provider’s domain with a detailed explanation of the error. If forwarding the user to the developer’s redirect URL is essential, it can be done in a safe manner to reduce the risk of phishing innocent users. 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.
Phishing innocent users remains the most successful attack method to compromise user credentials and breach your organization’s network in the process. Email protection systems are helpless against these attacks. By abusing OAuth infrastructure, these attacks deliver malicious emails to their targets undetected. Such attacks on PayPal can lead to theft of financial information such as credit cards. Phishing attacks on Microsoft can lead to fraud, intellectual property theft and more.
Phishing URL domains
Below is a list of all the URLs we observed malicious applications using to redirect users:
102871.z13.web.core.windows[.]net/redirect.htm
118921.z13.web.core.windows[.]net/redirect.htm
59328.z13.web.core.windows[.]net/redirect.htm
91829.z13.web.core.windows[.]net/redirect.htm
bewaio.z13.web.core.windows[.]net/redirect.htm
apqiuz.z13.web.core.windows[.]net/redirect.htm
cdoiaioa.z13.web.core.windows[.]net/redirect.htm
csadawzq.z13.web.core.windows[.]net/redirect.htm
cwasdcawz.z13.web.core.windows[.]net/redirect.htm
zoopqp.z13.web.core.windows[.]net/redirect.htm
7172981.z13.web.core.windows[.]net/redirect.htm
287191.z13.web.core.windows[.]net/redirect.htm
279102.z13.web.core.windows[.]net/redirect.htm
901829.z13.web.core.windows[.]net/redirect.htm
178710.z13.web.core.windows[.]net/redirect.htm
391722.z13.web.core.windows[.]net/redirect.htm
2910992.z13.web.core.windows[.]net/redirect.htm
40192.z13.web.core.windows[.]net/redirect.htm
618291.z13.web.core.windows[.]net/redirect.htm
817892.z13.web.core.windows[.]net/redirect.htm
528102.z13.web.core.windows[.]net/redirect.htm
116258.z13.web.core.windows[.]net/redirect.htm
29190.z13.web.core.windows[.]net/redirect.htm
49281.z13.web.core.windows[.]net/redirect.htm
23811.z13.web.core.windows[.]net/redirect.htm
49187.z13.web.core.windows[.]net/redirect.htm
39281.z13.web.core.windows[.]net/redirect.htm
49287.z13.web.core.windows[.]net/redirect.htm
12787.z13.web.core.windows[.]net/redirect.htm
51871.z13.web.core.windows[.]net/redirect.htm
19281.z13.web.core.windows[.]net/redirect.htm
49271.z13.web.core.windows[.]net/redirect.htm
39871.z13.web.core.windows[.]net/redirect.htm
172914.z13.web.core.windows[.]net/redirect.htm
127100.z13.web.core.windows[.]net/redirect.htm
39182.z13.web.core.windows[.]net/redirect.htm
cijuaiu.z13.web.core.windows[.]net/redirect.htm
38e1-138-199-58-114.ngrok[.]io/informationssk
66d0-185-91-121-4.ngrok[.]io/informationssk
769b-216-131-110-210.ngrok[.]io/informationssk
c578-143-202-163-94.ngrok[.]io/informationssk
f1e7-185-108-106-250.ngrok[.]io/informationssk
ff99-185-245-84-32.ngrok[.]io/informationssk
www.lifetivate[.]com/wp-admin/js
tuffgigmusic[.]com/imdmlm/pp
tuffgigmusic[.]com/immmnf/pp
tuffgigmusic[.]com/immmnn/pp
tuffgigmusic[.]com/impho/pp
i12313212111478.blogspot[.]com
i8974541122.blogspot[.]com
i98742138576.blogspot[.]com
id2021serviceupp.blogspot[.]com
montana.co[.]ke/pp
persiken[.]com/in
How Proofpoint can help
Proofpoint can help you detect, prevent and remediate the dangers from such attacks across email, web and the cloud with Proofpoint Targeted Attack Protection, Proofpoint Cloud App Security Broker and Proofpoint Premium Threat Information Services. Contact us for more information.
Subscribe to the Proofpoint Blog