Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

[Will Bartlett <[e-mail]>]

I tend to agree that the requirement to send errors back to the original domain is "over-zealous". It's also looping prone at scale - I've seen many a buggy https://contoso.example that issues a request to https://idp.example?redirect_uri=https://contoso.example<https://idp.example?redirect_uri=https:/contoso.example> and gets an error response https://contoso.example?error=invalid_request and promptly issues the same login request with an updated state value again - https://idp.example?redirect_uri=https://conoto.example&state= https://contoso.example?error%3Dinvalid_request. In practice, I think most large scale OAuth providers end up implementing some sort of loop breaking behavior (which is inevitably not-by-spec, as it returns a 200/4xx error page rather than a 302 redirect, even though the redirect_uri is "correct"). While not all of these looping cases come from invalid_request, probably the majority do.

With that said, I do it is useful for apps to get error reports with specific error descriptions to their domain. At first glance, I wonder why the STS couldn't choose the notify the app's error URI AJAX (or even S2S) - this would break loops and fix open redirects, while maintaining diagnosability.

Prompt=none is unfortunately, the one really hard case, as redirection is essential for the UX. I've previously had discussions around logic like:

  1.  Permit prompt=none if domainCheck(headers.Referer, request.redirectUri) == true
  2.  Permit prompt=none if login_hint present and that user has previously signed into the app in that browser session
  3.  Otherwise, deny prompt=none. (invalid_request)
There is a suggestion that #1 should cover the "optimistic auth" case and #2 should cover the "reauth" case, and those are all the use cases for prompt=none. This would block open redirectors, apart from the domain the user is already present on, which is really not much of an attack at all. However, "Referer" remains controversial.

I'm fairly dubious of phishing filters. They work ok at scale (i.e. for broad rather than targeted attacks), but domains are cheap. I'd rather see standards try to fix this, than patch it with phishing filters.

Thanks,
Will

From: OAuth <[e-mail]> On Behalf Of Brian Campbell
Sent: Friday, December 17, 2021 1:44 PM
To: Hans Zandbelt <[e-mail]>
Cc: oauth <[e-mail]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

Yeah, I think it has been discussed before. And if I'm understanding correctly, it is unfortunately a tricky area. It sounds like more or less the same thing as "Abuse: The Authorization Server As Open Redirector"<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-closing-redirectors-00%23section-2.1&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FZHy3ugosgps8fQGSP2UYUaTErspOOWWbdmIgcaqBg0%3D&reserved=0> described in the dormant WG draft, which is ultimately predicated on a client being registered with a malicious redirect URI. The twist in that Proofpoint article seems to be using it to evade detection by products/services that scan email for phishing links.

The "obvious" answer would be to prevent malicious client registration in the first place. But that's not tenable in many, many situations. Providing some more guidance about the importance of being as prudent as possible there couldn't hurt though.

A couple other things that could be considered (acknowledging that the details of providing guidance that might impact protocol is very tricky):

Require the redirect_uir parameter on the authorization request in all cases (even when only one is registered for a given client). This would make it so the malicious URL couldn't be entirely hidden from the email filters.

Relax how aggressively OAuth demands that the AS automatically redirect in error conditions. And either respond with a 400 directly (which just stops things at that point) or provide a meaningful interstitial page to the user before redirecting them (which at least helps users see something is amiss). I do think OAuth is a bit overzealous in automatically returning the user's browser context to the client in error conditions. There are some situations (like prompt=none) that rely on the behavior but in most cases it isn't necessary or helpful and can be problematic.

On Fri, Dec 17, 2021 at 1:59 PM Hans Zandbelt <[e-mail]<mailto:[e-mail]>> wrote:
AFAIK this topic has been discussed before, e.g.:
https://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FgIuIrxeXudRBg8L6RYGDElxrc4s%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=y7i0X48%2FZEYsM00yohZPva3E3Ijr8GgVGzF%2FCeMI%2BDQ%3D&reserved=0>

Hans.

On Fri, Dec 17, 2021 at 9:44 PM Pieter Kasselman <pieter.kasselman=[e-mail]<mailto:[e-mail]>> wrote:
The problem isn't invalid URLs but malicious ones. Given a choice between a sub-optimal user experience and a phished end-user, perhaps an option that allows the authorization server to handle the error, rather than redirecting can serve end-users better. But as Vittorio points, out, there are probably other options as well to consider. URL reputation services is another option, but problematic since they are imperfect and I expect hard to standardise to a point that creates a common minimum level of assurance (similar to any fraud calculation or risk score).

From: Warren Parad <wparad=[e-mail]<mailto:[e-mail]>>
Sent: Friday 17 December 2021 20:27
To: Pieter Kasselman <[e-mail]<mailto:[e-mail]>>
Cc: Vittorio Bertocci <[e-mail]<mailto:[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

You want to redirect on some errors because the last thing an AS wants is to leave the user in the AS because the user can't do anything there and the AS can't do anything either. It's just bad UX. But if the redirect url isn't valid, this is absolutely the time that the AS should keep the user there for user's protection.  Any AS redirecting the user to an invalid redirect url, isn't doing the right thing.

But that only solves the illegitimate phishing urls, it doesn't solve the class of problem where a phishing application is legitimately registered.


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nxOW61%2B9y7YmhKa6aUNjEx%2BgNmGfCFpirw6sx1MICq0%3D&reserved=0>.


On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman <pieter.kasselman=[e-mail]<mailto:[e-mail]>> wrote:
Agreed that the attackers goal is to bypass phishing filters and they found a way to achieve this by using an IdP that adheres to the standards. I don't have the context for the design choice to redirect on an error condition, but am curious why the IdP should not be allowed to handle the error condition, rather than redirect (or at least have the option to do so)?

From: OAuth <[e-mail]<mailto:[e-mail]>> On Behalf Of Vittorio Bertocci
Sent: Friday 17 December 2021 19:55
To: Warren Parad <wparad=[e-mail]<mailto:[e-mail]>>
Cc: oauth <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

The attack doesn't rely on redirecting to unregistered URLs, that's the problem.
The goal of the attack is to circumvent phishing filters, by presenting a URL from a legitimate domain (the AS) that eventually redirects to the actual phishing URL. The actual phishing page doesn't need to target the same authorization server, or an authorization server at all for that matter.
An attacker can register a legitimate app on any authorization server as a service, on their own tenant. The goal is just to have a starting URL that phishing filters won't block, and the attacker is in full control of the redirect URIs they register in their own tenant.

My take: it might be tricky to change the redirect on error behavior at this point, but we should at least note the issue in the security considerations/BCPs and possibly give some advice. For example, on top of my head: AS should expose their endpoints on a domain dedicated to OAuth/OIDC operations, and avoid using its top level domains (different area/service, but think herokuapp.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fherokuapp.com%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ddgp8nsuQKDWDNFAP3LlF0CRKXdK61%2B4YRRiqGddYJI%3D&reserved=0> vs heroku.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fheroku.com%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VXLtL1vCFvVfTbKQdP2ZHREm8wzh%2FCibPW5o98%2FzCi0%3D&reserved=0>) so that if a phishing filter decides to block direct links to the issuing endpoints will only impact things like IdP initiated flows (solvable by adding jumpstart endpoints on the RP anyway, just like IdP initiated sign in works in OIDC). I am sure there are lots of other things we can come up with that can make the problem better.

On Fri, Dec 17, 2021 at 5:00 AM Warren Parad <wparad=[e-mail]<mailto:[e-mail]>> wrote:
I think this just falls into the category of never redirect the user to a url that doesn't match one of the preregistered redirect urls (or logout urls for that matter). Any application that has redirects anywhere provides an opportunity for this attack vector, OAuth isn't unique in that way, it just is consistent and documented. And the 2.1 draft is pretty clear on this front:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-v2-1-04%23section-4.1.2.1&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=azPPkMHdIvZM4w0HIVcS%2FwgrzCd9WvHNVAbUAdKbl4I%3D&reserved=0>
   If the request fails due to a missing, invalid, or mismatching
   redirect URI, or if the client identifier is missing or invalid, the
   authorization server SHOULD inform the resource owner of the error
   and MUST NOT automatically redirect the user agent to the invalid
   redirect URI.

I want to call this attack vector "illegitimate phishing applications" which is easily blocked by preregistration and/or PARs. And is only a very small subset of phishing attacks with OAuth, of which the larger group is "legitimate phishing applications". An app can be registered correctly, and still issue a phishing attack as phishing attacks through OAuth are actually indistinguishable from standard user delegation. There is no way to prevent these without an application review before registration is completed, here's an example that cloned Google apps y creating a fake app called google defender: https://www.trendmicro.com/en_us/research/17/d/pawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trendmicro.com%2Fen_us%2Fresearch%2F17%2Fd%2Fpawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4RBL68YWSrTiCZrDrxBZJASwEcFyy7G1XHMjORF3cy0%3D&reserved=0>

If we can't protect against these latter ones, I hardly think protecting against the former is useful/interesting/valuable.


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309021764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nxOW61%2B9y7YmhKa6aUNjEx%2BgNmGfCFpirw6sx1MICq0%3D&reserved=0>.


On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>> wrote:

All,



An article was recently published discussing some OAuth Redirection Attacks to try to bypass phishing detection solutions. See the details of these attacks in the following link:



https://www.proofpoint.com/us/blog/cloud-security/microsoft-and-github-oauth-implementation-vulnerabilities-lead-redirection<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fblog%2Fcloud-security%2Fmicrosoft-and-github-oauth-implementation-vulnerabilities-lead-redirection&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309071753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Unfy21xWkDqH7w7Fe3qKSq8qVJLTXBsUkzo129Pwvpo%3D&reserved=0>




The article discusses attacks on Microsoft and GitHub, but these attacks are not unique to these companies.

The attacks take advantage of how OAuth handles error responses, which sends responses to the application's redirect URL.


I would like to get the thoughts of the working group on these types of attacks.

What is the best way to mitigate these attacks?

Do we need a new approach for handling errors with OAuth?


Regards,

 Rifaat

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309071753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dBKEZF8CDX%2FJ7asiHvElHqBv9%2Bw3UZZUcpxeJ411cgs%3D&reserved=0>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309071753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dBKEZF8CDX%2FJ7asiHvElHqBv9%2Bw3UZZUcpxeJ411cgs%3D&reserved=0>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309071753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dBKEZF8CDX%2FJ7asiHvElHqBv9%2Bw3UZZUcpxeJ411cgs%3D&reserved=0>


--
[e-mail]<mailto:[e-mail]>
ZmartZone IAM - www.zmartzone.eu<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zmartzone.eu%2F&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309071753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oEOw9XfdmFaBqH88tmGZDLQL8nk5CrNMYrQrP9Ii9VI%3D&reserved=0>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cwibartle%40microsoft.com%7C331dc63ebbb7434f519a08d9c1a683e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753743309071753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dBKEZF8CDX%2FJ7asiHvElHqBv9%2Bw3UZZUcpxeJ411cgs%3D&reserved=0>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.