Subject: [OAUTH-WG] Mix-up mitigation is not so easy...

From: Daniel Fett <[email-masked]>
Date: Wed, 28 Oct 2020 11:08:24 +0100

Hi all,

during my work to update the Security BCP, I stumbled upon a problem in
our current recommendations against mix-up attacks.

Until now, our understanding was that adding an "iss" parameter in the
authorization response and using a distinct redirect URI for each
configured issuer provided the same level of security. This is
unfortunately not the case when mix-up is combined with a client
impersonation attack.

Let's start with the "iss" parameter: The assumption is, that an AS
"knows" which issuer it belongs to. Therefore, an uncompromised AS will
always send the identifier for this (correct) issuer in the "iss"
parameter in the authorization response. The client will see that it
started the process with the attacker's issuer, but receives the
identifier for another issuer in the authorization response, and will
abort the interaction.

With the distinct redirect URIs, the situation is similar. Let's look at
how the client would defend against mix-up:

  * For the attacker's AS configuration (attacker Authorization
    Endpoint, attacker Token Endpoint), the client would register
    https://client.com/redir/attacker as the redirection URI at the
    attacker's AS.
  * For the honest AS configuration (honest Authorization Endpoint,
    honest Token Endpoint), the client would register
    https://client.com/redir/honest as the redirection URI at the honest AS.

In the normal mix-up attack, the following would happen:

  * The user selects "attacker" as AS.
  * The user is being redirected to the attacker's authorization endpoint.
  * The attacker redirects the user to the honest AS's authorization
    endpoint, replacing the client ID in the original authorization
    request with the client ID of the client at the honest AS.
  * The user authorizes the client at honest AS.
  * Honest AS redirects the user back to the client, using
    https://client.com/redir/honest as the redirect URI.
  * The client notices a mismatch between the redirection URI and the
    expected redirect URI (which would be .../attacker).

Therefore, the mix-up attack is mitigated. The problem is, however, that
the attacker can circumvent the protection by *registering a new client
with the honest AS, giving https://client.com/redir/attacker as the
redirection URI* and using this new client ID in step 3 of the attack.

This would mean that the client would see the attacker's redirect URI as
the incoming URI for the authorization response and would not detect the
attack. It would forward the authorization code to the token endpoint of
the attacker, who would be able to redeem it.

Note that the user would not grant access to the honest client, but to
the attacker's client. The attacker's client would need to "impersonate"
the honest client, i.e., using the same name, icon, etc.; This approach
is similar to existing OAuth phishing attacks with counterfeit clients,
however, in this case, a *redirect URI of the honest client* is used.
Therefore, the usual mitigation whereby the AS shows the redirect URI to
the user would not provide any protection (see also
https://tools.ietf.org/html/rfc6819#section-3.5).

What can we do against this attack?

  * PKCE does not protect against this attack, as the attacker would be
    able to change the code_challenge parameter.
  * I think that PAR and JAR probably won't help either, since the
    honest client "legitimately" speaks to the attacker's AS, who in
    turn speaks "legitimately" to the honest AS (as the attacker's
    client). All sides would use the correct endpoints and keys, and the
    attacker would be able to receive and modify the authorization
    request, forwarding it to the honest AS under his own client ID.
  * For the same reason, a DPoP-like sender-constraining of the
    authorization code is unlikely to help.
  * What would help is if client registrations would depend on an
    ACME-like demonstration of control over the origin of the redirect
    URI. This not something mandated for OAuth today and is unlikely to
    be seen in broad use.
  * The "iss" parameter solution is robust against this attack as long
    as an authorization server never returns an issuer controlled by the
    attacker. In essence, by declaring the issuer, the AS is providing a
    pointer to a metadata file which points to the "correct" token
    endpoint - this is why this solution is robust. We have shown the
    robustness of the "iss" solution in our formal analysis, but never
    analyzed the redirect uri solution formally.

For the security BCP, this means that we depend on the "iss" parameter
solution even more. (It also means that OAuth 2.1 should probably
include this parameter.)

We need to think about how we can proceed with the security BCP without
too much delay. 

Sorry for poking another hole into the spec,
Daniel

-- 
https://danielfett.de

---

From: Warren Parad <[email-masked]>
Date: Wed, 28 Oct 2020 12:00:05 +0100

I would likewise assume that issuer validation is always required. But
maybe I hadn't been thinking about this enough. Is there an alternative to
validating it, and implicitly trusting it? Because as you pointed out
either demonstrated control over valid redirect URIs or really any other
secondary mechanism would be required. Perhaps I'm missing something though.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.

On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett <[email-masked]> wrote:

> always send the identifier for this (correct) issuer in the "iss" parameter
> in the authorization response. The client will see that it started the
> process with the attacker's issuer, but receives the identifier for another
> issuer in the authorization response, and will abort the interaction.
>
>    - For the attacker's AS configuration (attacker Authorization
>    - For the honest AS configuration (honest Authorization Endpoint,
>    - The user selects "attacker" as AS.
>    - The user is being redirected to the attacker's authorization
>    endpoint.
>    - The attacker redirects the user to the honest AS's authorization
>    endpoint, replacing the client ID in the original authorization request
>    with the client ID of the client at the honest AS.
>    - The user authorizes the client at honest AS.
>    - Honest AS redirects the user back to the client, using
>    - The client notices a mismatch between the redirection URI and the
> with the honest AS, giving https://client.com/redir/attacker
> <https://client.com/redir/attacker> as the redirection URI* and using
> this new client ID in step 3 of the attack.
>
> Note that the user would not grant access to the honest client, but to the
> attacker's client. The attacker's client would need to "impersonate" the
> honest client, i.e., using the same name, icon, etc.; This approach is
> similar to existing OAuth phishing attacks with counterfeit clients,
>    - PKCE does not protect against this attack, as the attacker would be
>    - I think that PAR and JAR probably won't help either, since the
>    honest client "legitimately" speaks to the attacker's AS, who in turn
>    speaks "legitimately" to the honest AS (as the attacker's client). All
>    sides would use the correct endpoints and keys, and the attacker would be
>    able to receive and modify the authorization request, forwarding it to the
>    honest AS under his own client ID.
>    - For the same reason, a DPoP-like sender-constraining of the
>    - What would help is if client registrations would depend on an
>    ACME-like demonstration of control over the origin of the redirect URI.
>    This not something mandated for OAuth today and is unlikely to be seen in
>    broad use.
>    - The "iss" parameter solution is robust against this attack as long
>    pointer to a metadata file which points to the "correct" token endpoint -
>    this is why this solution is robust. We have shown the robustness of the
>    "iss" solution in our formal analysis, but never analyzed the redirect uri
>    solution formally.
>
> solution even more. (It also means that OAuth 2.1 should probably include
> this parameter.)
>
> -- https://danielfett.de
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Daniel Fett <[email-masked]>
Date: Wed, 28 Oct 2020 12:58:46 +0100

Am 28.10.20 um 12:00 schrieb Warren Parad:
> maybe I hadn't been thinking about this enough. Is there an
> alternative to validating it, and implicitly trusting it? Because as
> you pointed out either demonstrated control over valid redirect URIs
> or really any other secondary mechanism would be required. Perhaps I'm
> missing something though.

When using "iss" to mitigate mix-up attacks, we're essentially telling
the client where submitting the auth code is okay. Since this chain of
pointers starts at the AS (→ issuer ID → metadata document → token
endpoint URL), there's no further validation needed: In this direction,
we can assume that every pointer points to an uncompromised component.

A malicious issuer could mix and match PAR/authorization/token/userinfo
endpoint URLs and thereby build a different chain, but I think there's
really not that much that can go wrong there that wouldn't be covered by
the "iss" defense: https://danielfett.de/2020/05/04/mix-up-revisited/

-Daniel

> On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     during my work to update the Security BCP, I stumbled upon a
>     problem in our current recommendations against mix-up attacks.
>
>     Until now, our understanding was that adding an "iss" parameter in
>     the authorization response and using a distinct redirect URI for
>     each configured issuer provided the same level of security. This
>     is unfortunately not the case when mix-up is combined with a
>     client impersonation attack.
>
>     Let's start with the "iss" parameter: The assumption is, that an
>     AS "knows" which issuer it belongs to. Therefore, an uncompromised
>     AS will always send the identifier for this (correct) issuer in
>     the "iss" parameter in the authorization response. The client will
>     see that it started the process with the attacker's issuer, but
>     receives the identifier for another issuer in the authorization
>     response, and will abort the interaction.
>
>     With the distinct redirect URIs, the situation is similar. Let's
>     look at how the client would defend against mix-up:
>
>         https://client.com/redir/attacker as the redirection URI at
>         the attacker's AS.
>       * For the honest AS configuration (honest Authorization
>         Endpoint, honest Token Endpoint), the client would register
>       * The attacker redirects the user to the honest AS's
>         authorization endpoint, replacing the client ID in the
>         original authorization request with the client ID of the
>         client at the honest AS.
>       * The client notices a mismatch between the redirection URI and
>         the expected redirect URI (which would be .../attacker).
>
>     Therefore, the mix-up attack is mitigated. The problem is,
>     however, that the attacker can circumvent the protection by
>     *registering a new client with the honest AS, giving
>     https://client.com/redir/attacker as the redirection URI* and
>     using this new client ID in step 3 of the attack.
>
>     This would mean that the client would see the attacker's redirect
>     URI as the incoming URI for the authorization response and would
>     not detect the attack. It would forward the authorization code to
>     the token endpoint of the attacker, who would be able to redeem it.
>
>     Note that the user would not grant access to the honest client,
>     but to the attacker's client. The attacker's client would need to
>     "impersonate" the honest client, i.e., using the same name, icon,
>     etc.; This approach is similar to existing OAuth phishing attacks
>     with counterfeit clients, however, in this case, a *redirect URI
>     of the honest client* is used. Therefore, the usual mitigation
>     whereby the AS shows the redirect URI to the user would not
>     provide any protection (see also
>       * PKCE does not protect against this attack, as the attacker
>         would be able to change the code_challenge parameter.
>         honest client "legitimately" speaks to the attacker's AS, who
>         in turn speaks "legitimately" to the honest AS (as the
>         attacker's client). All sides would use the correct endpoints
>         and keys, and the attacker would be able to receive and modify
>         the authorization request, forwarding it to the honest AS
>         under his own client ID.
>         ACME-like demonstration of control over the origin of the
>         redirect URI. This not something mandated for OAuth today and
>         is unlikely to be seen in broad use.
>       * The "iss" parameter solution is robust against this attack as
>         long as an authorization server never returns an issuer
>         controlled by the attacker. In essence, by declaring the
>         issuer, the AS is providing a pointer to a metadata file which
>         points to the "correct" token endpoint - this is why this
>         solution is robust. We have shown the robustness of the "iss"
>         solution in our formal analysis, but never analyzed the
>         redirect uri solution formally.
>
>     For the security BCP, this means that we depend on the "iss"
>     parameter solution even more. (It also means that OAuth 2.1 should
>     probably include this parameter.)
>
>     We need to think about how we can proceed with the security BCP
>     without too much delay. 
>
>     [email-masked] <mailto:[email-masked]>

-- 
https://danielfett.de