Subject: [OAUTH-WG] OAuth Redirection Attacks

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 16 Dec 2021 15:04:12 -0500

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

---

From: Warren Parad <[email-masked]>
Date: Fri, 17 Dec 2021 13:59:56 +0100

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 <https://authress.io/>.

On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <[email-masked]>
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:
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 17 Dec 2021 11:55:24 -0800

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=
[email-masked]> wrote:

> On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <
> [email-masked]> wrote:
>
>> All,
>>
>>
>> Attacks to try to bypass phishing detection solutions. See the details
>> of these attacks in the following link:
>>
>>
>>

---

From: Pieter Kasselman <[email-masked]>
Date: Fri, 17 Dec 2021 20:22:44 +0000

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 <[email-masked]> On Behalf Of Vittorio Bertocci
Sent: Friday 17 December 2021 19:55
To: Warren Parad <wparad=[email-masked]>
Cc: oauth <[email-masked]>
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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744175760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UKsLcroZJVlu8HPo2lG9oFGeAT5RZsTUcEbhD0pZP8M%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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744175760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9hsxq2ZxK%2FwBJTe5RGIFZSTJ0icXcvEiLsBDXhdn8Rk%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=[email-masked]<mailto:[email-masked]>> 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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3EUcWa6IS4l67nLHRSP13J0Q0SAgNXCDiO%2B22GSoNLM%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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iAkKMqOFq9WaCFyO46PmxbPKNEY8Q%2FGrnJ9GMw06EPo%3D&reserved=0>

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

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HpY3P0HundCwtRQ6yYmnoHLQROHofah%2BZ%2B3EMN2%2FkRk%3D&reserved=0>.

On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> 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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=w1Ka1ztLdHnvwzngw%2BRbAlgv97RaTxbIYlO%2FSCN2lrc%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.

Regards,

 Rifaat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QlSEfYrRZSkF4Iwfux03kcUyD57bDFTUjJqAYJghayM%3D&reserved=0>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QlSEfYrRZSkF4Iwfux03kcUyD57bDFTUjJqAYJghayM%3D&reserved=0>

---

From: Warren Parad <[email-masked]>
Date: Fri, 17 Dec 2021 21:26:53 +0100

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

On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman <pieter.kasselman=
[email-masked]> 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 <[email-masked]> *On Behalf Of *Vittorio Bertocci
> *Sent:* Friday 17 December 2021 19:55
> *To:* Warren Parad <wparad=[email-masked]>
> *Cc:* oauth <[email-masked]>
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks
>
>
>
> 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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744175760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UKsLcroZJVlu8HPo2lG9oFGeAT5RZsTUcEbhD0pZP8M%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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744175760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9hsxq2ZxK%2FwBJTe5RGIFZSTJ0icXcvEiLsBDXhdn8Rk%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.
>
>
>
> <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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3EUcWa6IS4l67nLHRSP13J0Q0SAgNXCDiO%2B22GSoNLM%3D&reserved=0>
>
> <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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iAkKMqOFq9WaCFyO46PmxbPKNEY8Q%2FGrnJ9GMw06EPo%3D&reserved=0>
>
>
>
> *Warren Parad*
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HpY3P0HundCwtRQ6yYmnoHLQROHofah%2BZ%2B3EMN2%2FkRk%3D&reserved=0>
> .
>
>
>
>
>
> An article was recently published discussing some *OAuth Redirection
> Attacks* to try to bypass *phishing* detection solutions. See the details
> <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%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=w1Ka1ztLdHnvwzngw%2BRbAlgv97RaTxbIYlO%2FSCN2lrc%3D&reserved=0>
>
>
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QlSEfYrRZSkF4Iwfux03kcUyD57bDFTUjJqAYJghayM%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ccbc8efd229ae4b9617e908d9c1974378%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753677744226186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QlSEfYrRZSkF4Iwfux03kcUyD57bDFTUjJqAYJghayM%3D&reserved=0>
>
>

---

From: Pieter Kasselman <[email-masked]>
Date: Fri, 17 Dec 2021 20:44:05 +0000

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=[email-masked]>
Sent: Friday 17 December 2021 20:27
To: Pieter Kasselman <[email-masked]>
Cc: Vittorio Bertocci <[email-masked]>; oauth <[email-masked]>
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%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=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Vittorio Bertocci
Sent: Friday 17 December 2021 19:55
To: Warren Parad <wparad=[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

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.

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>

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>

[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>.

All,

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>

Regards,

 Rifaat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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>

---

From: Hans Zandbelt <[email-masked]>
Date: Fri, 17 Dec 2021 21:59:13 +0100

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=
[email-masked]> 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=[email-masked]>
> *Sent:* Friday 17 December 2021 20:27
> *To:* Pieter Kasselman <[email-masked]>
> *Cc:* Vittorio Bertocci <[email-masked]>; oauth <[email-masked]>
> *Subject:* Re: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks
>
>
>
> <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>
> .
>
>
>
>
>
> <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>)
> <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>
>
> <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>
>
>
>
> <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>
> .
>
>
>
>
>
> <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>
>
>
>
>
>
> <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>
>
> <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>
>

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Dec 2021 14:44:23 -0700

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://datatracker.ietf.org/doc/html/draft-ietf-oauth-closing-redirectors-00#section-2.1>
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 <[email-masked]>
wrote:

>> 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.
>>
>>
>>
>> *MUST NOT automatically redirect the user agent to the invalid
>>  redirect URI*.
>>
>>
>>
>> Attacks* to try to bypass *phishing* detection solutions. See the
>> details of these attacks in the following link:
>>
>>
>>
>>

-- 
_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._

---

From: Nov Matake <[email-masked]>
Date: Sat, 18 Dec 2021 11:18:00 +0900

Phishing filters can simply handle all OAuth AuthZ request like URLs in emails malicious.

> 2021/12/18 6:45、Brian Campbell <bcampbell=[email-masked]>のメール:
> 
> 
> 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 <[email-masked]> wrote:
>> On Fri, Dec 17, 2021 at 9:44 PM Pieter Kasselman <pieter.kasselman=[email-masked]> 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).
>>> 
>>>  
>>> 
>>> 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=[email-masked]> 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)?
>>> 
>>>  
>>> 
>>> 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=[email-masked]> wrote:
>>> 
>>> 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
>>> 
>>>  
>>> 
>>> Secure your user data with IAM authorization as a service. Implement Authress.
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <[email-masked]> wrote:
>>> 
>>> All,
>>>  
>>> The attacks take advantage of how OAuth handles error responses, which sends responses to the application’s redirect URL.
>>>  
>>> 
> 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
> [email-masked]

---

From: David Waite <[email-masked]>
Date: Fri, 17 Dec 2021 23:11:26 -0700

> On Dec 17, 2021, at 2:44 PM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 

The problem is that if prompt=none still requires redirection without prompt or interstitial, someone wishing to treat dynamic registrations of malicious sites as clients will just start using prompt=none. Likewise, a site could still attempt to manipulate the user to release information by imitating an extension to the authentication process, such as an "expired password change" prompt.

I agree with Nov Matake's comment - phishing link email filters should treat all OAuth URLs as suspect, as OAuth has several security-recommended features like state and PKCE which do not work as expected/reliably with email. Filters integrated into the browser (such as based on the unsafe site list in Chrome) should not need changes, as they will warn on redirect to the known malicious site.

We should also continue to push as an industry for authentication technologies like WebAuthn (as well as mutual TLS and Kerberos) which are phishing resistant. We are really talking about failure of a single phishing mitigation for _known_ malicious sites - the opportunity to use any unknown malicious site or a compromised legitimate site remains open even if we do suggest changes to error behavior.

-DW

---

From: George Fletcher <[email-masked]>
Date: Sat, 18 Dec 2021 10:10:42 -0500

Given the attack is based on a successfully registered callback URL that 
is malicious, we can also look to the Authorization Server to run more 
checks on the registered callback URLs (e.g. check against the "unsafe" 
URL list). Not a 100% solution by any means but could help with reduce 
the impact. Additionally, making sure the AS can easily revoke any 
client_id and have that take effect quickly.

Another potential option would be to not allow prompt=none (or automatic 
redirects) from contexts where the user hasn't first gone through a full 
authentication flow or at least allow the AS to display UI at it's 
discretion. Though this will definitely break some flows :(

This at least illuminates one of the dangers of allowing a wide open 
dynamic client registration model :)

Thanks,
George

---

From: Warren Parad <[email-masked]>
Date: Sat, 18 Dec 2021 16:24:45 +0100

I also 100% with the recommendation for phishing detectors treat all
perceived OAuth links as malicious in emails. It actually isn't hard to
know that there is a link embedded in a url query parameter. So I would
just take the next step of treating all urls with urls as query parameters
as malicious.

There are exactly zero reasons why a site can't use it's own javascript
redirection unless it's domain has been marked as malicious. The only
conceivable reason is a third party is providing tracking as a service, and
then that's even a better reason to potentially block these.

Phishing can still use PKCE and PAR, nor does WebAuthN provide protection
from this problem.

Warren Parad

Founder, CTO

On Sat, Dec 18, 2021 at 4:11 PM George Fletcher <gffletch=
[email-masked]> wrote:

> >> On Dec 17, 2021, at 2:44 PM, Brian Campbell <bcampbell=
> [email-masked]> wrote:
> >>
> >> 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 problem is that if prompt=none still requires redirection without
> prompt or interstitial, someone wishing to treat dynamic registrations of
> malicious sites as clients will just start using prompt=none. Likewise, a
> site could still attempt to manipulate the user to release information by
> imitating an extension to the authentication process, such as an "expired
> password change" prompt.
> >
> > I agree with Nov Matake's comment - phishing link email filters should
> treat all OAuth URLs as suspect, as OAuth has several security-recommended
> features like state and PKCE which do not work as expected/reliably with
> email. Filters integrated into the browser (such as based on the unsafe
> site list in Chrome) should not need changes, as they will warn on redirect
> to the known malicious site.
> >
> > We should also continue to push as an industry for authentication
> technologies like WebAuthn (as well as mutual TLS and Kerberos) which are
> phishing resistant. We are really talking about failure of a single
> phishing mitigation for _known_ malicious sites - the opportunity to use
> any unknown malicious site or a compromised legitimate site remains open
> even if we do suggest changes to error behavior.
> >
> > -DW
> >

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 18 Dec 2021 08:57:16 -0800

Agreed. Most of dyn reg cases we were thinking about occurred because there was a need to register each copy of the same client software. The software statement was intended to allow the registration endpoint recognize software and to fix things like endpoints. 

Automatic registration of singletons is definitely suspect.  Do we need best practices?

Phil

> On Dec 18, 2021, at 7:11 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> Given the attack is based on a successfully registered callback URL that is malicious, we can also look to the Authorization Server to run more checks on the registered callback URLs (e.g. check against the "unsafe" URL list). Not a 100% solution by any means but could help with reduce the impact. Additionally, making sure the AS can easily revoke any client_id and have that take effect quickly.
> 
> Another potential option would be to not allow prompt=none (or automatic redirects) from contexts where the user hasn't first gone through a full authentication flow or at least allow the AS to display UI at it's discretion. Though this will definitely break some flows :(
> 
> This at least illuminates one of the dangers of allowing a wide open dynamic client registration model :)
> 
> Thanks,
> George
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 19 Dec 2021 10:08:52 +0100

I think there are two options:
1) validation of the organization/person behind a certain client in order to be able to go after them in case of abuse 
2) don’t redirect in an error condition

However, even a successful OAuth process can result in a phishing attack. So I don‘t think (2) will help entirely.

Treating OAuth authorization links as phishing attempts sounds reasonable to me.

> Am 18.12.2021 um 16:25 schrieb Warren Parad <wparad=[email-masked]>:
> 
> 
> I also 100% with the recommendation for phishing detectors treat all perceived OAuth links as malicious in emails. It actually isn't hard to know that there is a link embedded in a url query parameter. So I would just take the next step of treating all urls with urls as query parameters as malicious.
> 
> There are exactly zero reasons why a site can't use it's own javascript redirection unless it's domain has been marked as malicious. The only conceivable reason is a third party is providing tracking as a service, and then that's even a better reason to potentially block these.
> 
> Phishing can still use PKCE and PAR, nor does WebAuthN provide protection from this problem.
> 
> 
> Warren Parad
> Founder, CTO
>> On Sat, Dec 18, 2021 at 4:11 PM George Fletcher <gffletch=[email-masked]> wrote:

---

From: Will Bartlett <[email-masked]>
Date: Tue, 21 Dec 2021 18:20:45 +0000

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 <[email-masked]> On Behalf Of Brian Campbell
Sent: Friday, December 17, 2021 1:44 PM
To: Hans Zandbelt <[email-masked]>
Cc: oauth <[email-masked]>
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.

On Fri, Dec 17, 2021 at 1:59 PM Hans Zandbelt <[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>>
Sent: Friday 17 December 2021 20:27
To: Pieter Kasselman <[email-masked]<mailto:[email-masked]>>
Cc: Vittorio Bertocci <[email-masked]<mailto:[email-masked]>>; oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

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>.

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.

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>

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>

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>.

All,

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>

Regards,

 Rifaat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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>

--
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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.