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

[Hans Zandbelt <[e-mail]>]

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=
[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]>
> *Sent:* Friday 17 December 2021 20:27
> *To:* Pieter Kasselman <[e-mail]>
> *Cc:* Vittorio Bertocci <[e-mail]>; oauth <[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: 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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D&reserved=0>
> .
>
>
>
>
>
> On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman <pieter.kasselman=
> [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]> *On Behalf Of *Vittorio Bertocci
> *Sent:* Friday 17 December 2021 19:55
> *To:* Warren Parad <wparad=[e-mail]>
> *Cc:* oauth <[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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6oiRh6TMVJnXYUGdDJt%2BLQQI0gCtOs7au%2BU7ctOd%2Bjo%3D&reserved=0>
> vs heroku.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fheroku.com%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=egS2AEI1FmpbL09upMutgGCUtpgyEn2l1FtdDb7WCdI%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]> 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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M7ZtR%2BTYVIVzXZmHaeJS6rGVLC84RUisnfl5KCF0rHg%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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9kKah9zgc66ew2AD5iGhgX2Qnzbnq3UJ%2FHoHsuzUU5w%3D&reserved=0>
>
>
>
> If we can't protect against these latter ones, I hardly think protecting
> against the former is useful/interesting/valuable.
>
>
> [image: 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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D&reserved=0>
> .
>
>
>
>
>
> On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <
> [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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=itNmcvlkuKrPzG6%2F23Iod8zyH%2FqSjhcNuxJMw3dZslU%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]
> 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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696442034307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9S1YCx61RDItp9TtylYb4bgxMTABCZJ9MbjwUHV%2FStM%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> [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%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696442034307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9S1YCx61RDItp9TtylYb4bgxMTABCZJ9MbjwUHV%2FStM%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu