Phishing filters can simply handle all OAuth AuthZ request like URLs in emails malicious.
> 2021/12/18 6:45、Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org>のメール: > > > 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" 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 <hans.zandb...@zmartzone.eu> > wrote: >> AFAIK this topic has been discussed before, e.g.: >> https://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s/ >> >> Hans. >> >> On Fri, Dec 17, 2021 at 9:44 PM Pieter Kasselman >> <pieter.kasselman=40microsoft....@dmarc.ietf.org> 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=40rhosys...@dmarc.ietf.org> >>> Sent: Friday 17 December 2021 20:27 >>> To: Pieter Kasselman <pieter.kassel...@microsoft.com> >>> Cc: Vittorio Bertocci <vitto...@auth0.com>; oauth <oauth@ietf.org> >>> 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. >>> >>> >>> >>> >>> Warren Parad >>> Founder, CTO >>> Secure your user data with IAM authorization as a service. Implement >>> Authress. >>> >>> >>> >>> >>> >>> On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman >>> <pieter.kasselman=40microsoft....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> On Behalf Of Vittorio Bertocci >>> Sent: Friday 17 December 2021 19:55 >>> To: Warren Parad <wparad=40rhosys...@dmarc.ietf.org> >>> Cc: oauth <oauth@ietf.org> >>> 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 vs heroku.com) 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=40rhosys...@dmarc.ietf.org> 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 >>> >>> 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 >>> >>> >>> >>> If we can't protect against these latter ones, I hardly think protecting >>> against the former is useful/interesting/valuable. >>> >>> >>> >>> >>> Warren Parad >>> Founder, CTO >>> Secure your user data with IAM authorization as a service. Implement >>> Authress. >>> >>> >>> >>> >>> >>> On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef >>> <rifaat.s.i...@gmail.com> 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 >>> >>> >>> >>> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> hans.zandb...@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > 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._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
