Subject: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Feb 2016 21:27:17 +0100

Hi all,

when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation'
solution <draft-jones-oauth-mix-up-mitigation> I wasn't expecting such a
heavy debate on the list. While the call for adoption is still ongoing I
would like to share my view as someone who has to judge consensus in a
few days together with Derek.

Regardless of where we are with respect to oauth-meta vs.
draft-jones-oauth-mix-up-mitigation we should keep an eye on the threats
we are trying to address (and we have to document them).

Here is how I would summarize the situation after reviewing the drafts,
blog posts and various emails sent to the list.

We have two types of threats:

#1: Threat described in the papers referenced in my email to the list
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html

The attack assumes that '... the presence of a network attacker who can
manipulate the request in which the user sends her identity to the RP as
well as the corresponding response to this request ...' (see page 15 of
http://arxiv.org/pdf/1601.01229v2.pdf).

I believe that this threat is well documented (at least in the paper).

#2: Cut-and-Paste Attacks

Here things get a bit more difficult since the threat is less well
described. In Section 7.3 of
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 Mike
makes an attempt to describe the attack and refers to Section 4.4.1.13
of RFC 6819, which talks about 'Code Substitution'. I am not convinced
that the description in RFC 6819 exactly matches the intention of
Section 7.3 of draft-jones-oauth-mix-up-mitigation-01 but I might be
misinterpreting.

Anyway, here is a copy-and-paste from the draft:

   A "cut-and-paste" attack is performed
   by the attacker creating what appears to be a legitimate
   authorization response, but that substitutes some of the response
   parameter values with values of the attacker's choosing.

Clearly, this attack makes different assumptions than what is stated in
the papers listed under item #1. It appears that the attacker will have
to be on the users device /browser itself. If that's true then the text
needs to state that.

Nat also provides a description of a similar attack in his blog post
under the name of 'Code Phishing' at
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
In his description the attacker assumption is that the developer is
tricked into re-configuring the token endpoint so that the attacker is
able to obtain the authorization code.

While I believe the group is well advised to tackle the attack described
in item #1 to mitigate the attacks discovered late last year. I am
curious whether the group also sees the mitigation of threat #2 in scope
of this document. In some sense, one could argue that cut-and-paste is
more generic and a concern also for those cases where an OAuth client
does not talk to multiple ASs.

So, here are my questions:

- Can we describe the threat #2 in more details and by stating the
assumptions about the attacker?

I believe that this is important for understanding the attack within the
participants of the group but also for those who stumble over our
documents. Once we have a good description we should move on and answer
the next two questions:

- Should the document describe mitigations for attacks #1 and #2?

- Should the solution mandate a solution for dealing with both attacks?

Finally, we can talk about the details of the attack mitigation itself.

As far as the work from Mike (oauth-mix-up-mitigation) and Nat
(oauth-meta) is concerned Derek and I will find ways to ensure that the
prior work by all involved participants is appropriately attributed and
acknowledged!

Ciao
Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 6 Feb 2016 12:32:37 +0100

Hi Hannes,

#2 is not directly described in the paper but was used to replay the 
code/token the attacker obtained via #1. In my observation, the 
discussion in Darmstadt has shown that OAuth (and its built-in 
mitigations) so far focused on preventing code/token leakage but we lake 
mitigation for replay in this particular case.

#2 does not require the attacker to control the network or the victim's 
device. The attacker (using #1 or other attacks, e.g. on referrer 
headers or log files) obtains a code and injects this code into a 
legitimate OAuth/OIDC flow on its device. All she has to do is starting 
a authz code flow on the legitimate client, the particular code was 
issued for, and replace the code in the response from the AS. From the 
client's perspective, the response looks ok, since it carries the 
correct state value bound to the client in the particular user agent 
(since this is not a XSRF). But since there is no way (currently) to 
bind the code to a certain user agent, the client would accept the code 
and exchange it for token(s) on the AS. That gives the attacker access 
to resources of the victim and/or impersonates the attacker as the victim.

There are several way to mitigate this issue:
- OIDC has the "code id_token" response type, which uses nounce and 
c_hash in the id_token to bind the code to the user agent session
- in Darmstadt we came up with the idea to utilize the state value for 
that purpose.

Do we need to describe the threat and mitigation if 
draft-jones-oauth-mix-up-mitigation? I don't think so.
We could describe the mechanisms in a different draft.

I personally would prefer (and Phil already states this as well) the WG 
to work on a single draft, providing a consolidated view on all threats 
caused by the more dynamic usage of OAuth. We could also include all 
threats/mitigations/issues we have seen in the wild since RFC 6749 was 
published. This would also include stronger advice regarding XSRF 
prevention and open redirectors. I don't think we serve the community 
well be spreading those issues and mitigation over 3 or 4 drafts.

best regards,
Torsten.

Am 04.02.2016 um 21:27 schrieb Hannes Tschofenig:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Sat, 6 Feb 2016 11:58:43 -0300

I think Toresen states it well.

The reason we looked at 2 again is that #1 in some of the attacks was being used to leak the code.  
In some of those cases the attacker had the client credentials and could use the directly to get access tokens.

In other cases the attacker doesn’t have the client credentials, but could still get access to the information protected  by the API by presenting the code back to the client as part of a new flow, and bind it to a new account or if the clint is unwise and using the code for authentication, impersonate the user.

There are certainly other ways an attacker could get code, via logs, open redirectors etc.
The closest mention of this in 6819 is sec 4.4.1.13 ,  but that considered  two clients with two client_id.
that was mitigated by having the client send it’s client_id with code to exchange it.

The difference with 2 is that only one client_id is used, and that is not mitigated by the current counter measures in 6819.

Perhaps referring to 6819 sec 4.4.1.13 is a distraction, in this case.   We however were concerned at the time about codes leaking and being replayed but missed some of the ways that could happen.

The two opportunities that we are leaving for attackers,  1 not knowing who is sending the authorization response, and not tying the authorization request and response to the same browser instance open a whole world of attacks.

What we think currently is that there are two basic flaws that are being exploited (some attacks use one or the other and some use them together) .   We should probably keep the fixes separate from documents that are more how to guides to attack un-patched clients.

Both issues are around the client being mislead or confused by an authorization response, in that it is coming back from the wrong place or in the wrong browser instance.  That is why the two mitigations probably belong in the same document.

John B.

> On Feb 6, 2016, at 8:32 AM, Torsten Lodderstedt <[email-masked]> wrote
> 
> Hi Hannes,
> 
> #2 is not directly described in the paper but was used to replay the code/token the attacker obtained via #1. In my observation, the discussion in Darmstadt has shown that OAuth (and its built-in mitigations) so far focused on preventing code/token leakage but we lake mitigation for replay in this particular case.
> 
> #2 does not require the attacker to control the network or the victim's device. The attacker (using #1 or other attacks, e.g. on referrer headers or log files) obtains a code and injects this code into a legitimate OAuth/OIDC flow on its device. All she has to do is starting a authz code flow on the legitimate client, the particular code was issued for, and replace the code in the response from the AS. From the client's perspective, the response looks ok, since it carries the correct state value bound to the client in the particular user agent (since this is not a XSRF). But since there is no way (currently) to bind the code to a certain user agent, the client would accept the code and exchange it for token(s) on the AS. That gives the attacker access to resources of the victim and/or impersonates the attacker as the victim.
> 
> - OIDC has the "code id_token" response type, which uses nounce and c_hash in the id_token to bind the code to the user agent session
> - in Darmstadt we came up with the idea to utilize the state value for that purpose. 
> 
> Do we need to describe the threat and mitigation if draft-jones-oauth-mix-up-mitigation? I don't think so.
> I personally would prefer (and Phil already states this as well) the WG to work on a single draft, providing a consolidated view on all threats caused by the more dynamic usage of OAuth. We could also include all threats/mitigations/issues we have seen in the wild since RFC 6749 was published. This would also include stronger advice regarding XSRF prevention and open redirectors. I don't think we serve the community well be spreading those issues and mitigation over 3 or 4 drafts.
> 
> best regards,
> Torsten. 
> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html>
>> 
>> http://arxiv.org/pdf/1601.01229v2.pdf <http://arxiv.org/pdf/1601.01229v2.pdf>).
>> 
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 <https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01> Mike
>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 09 Feb 2016 03:23:37 +0000

I support keeping those two in a single document.

They actually belong to a same class of problem: the problem of accepting
an input from an untrusted / un-protected source, i.e., the authorization
response.
When this vulnerability is applied to the 'state', it opens up the chance
of authorization code being stollen through a rogue token endpoint.
When it is applied to the authorization code, then it is a cut-n-paste
attack.

The reason why 'code id_token' response type is protected in OIDC is that
the authorization response is integrity protected and the origin
authenticated.

Nat

2016年2月6日(土) 23:59 John Bradley <[email-masked]>:

> In other cases the attacker doesn’t have the client credentials, but could
> still get access to the information protected  by the API by presenting the
> code back to the client as part of a new flow, and bind it to a new account
> or if the clint is unwise and using the code for authentication,
> impersonate the user.
>
> The difference with 2 is that only one client_id is used, and that is not
> mitigated by the current counter measures in 6819.
>
> Perhaps referring to 6819 sec 4.4.1.13 is a distraction, in this case.
> We however were concerned at the time about codes leaking and being
> replayed but missed some of the ways that could happen.
>
> The two opportunities that we are leaving for attackers,  1 not knowing
> who is sending the authorization response, and not tying the authorization
> request and response to the same browser instance open a whole world of
> attacks.
>
> What we think currently is that there are two basic flaws that are being
> exploited (some attacks use one or the other and some use them together) .
>   We should probably keep the fixes separate from documents that are more
> how to guides to attack un-patched clients.
>
> Both issues are around the client being mislead or confused by an
> authorization response, in that it is coming back from the wrong place or
> in the wrong browser instance.  That is why the two mitigations probably
> belong in the same document.
>
> John B.
>
>
>
> code/token the attacker obtained via #1. In my observation, the discussion
> in Darmstadt has shown that OAuth (and its built-in mitigations) so far
> focused on preventing code/token leakage but we lake mitigation for replay
> in this particular case.
>
> device. The attacker (using #1 or other attacks, e.g. on referrer headers
> or log files) obtains a code and injects this code into a legitimate
> OAuth/OIDC flow on its device. All she has to do is starting a authz code
> flow on the legitimate client, the particular code was issued for, and
> replace the code in the response from the AS. From the client's
> perspective, the response looks ok, since it carries the correct state
> value bound to the client in the particular user agent (since this is not a
> XSRF). But since there is no way (currently) to bind the code to a certain
> user agent, the client would accept the code and exchange it for token(s)
> on the AS. That gives the attacker access to resources of the victim and/or
> impersonates the attacker as the victim.
>
> - OIDC has the "code id_token" response type, which uses nounce and c_hash
> in the id_token to bind the code to the user agent session
> I personally would prefer (and Phil already states this as well) the WG to
> work on a single draft, providing a consolidated view on all threats caused
> by the more dynamic usage of OAuth. We could also include all
> prevention and open redirectors. I don't think we serve the community well
> be spreading those issues and mitigation over 3 or 4 drafts.
>
> best regards,
> Torsten.
>
> #1: Threat described in the papers referenced in my email to the listhttp://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
>
> well as the corresponding response to this request ...' (see page 15 ofhttp://arxiv.org/pdf/1601.01229v2.pdf).
>
> described. In Section 7.3 ofhttps://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 Mike
> under the name of 'Code Phishing' athttp://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>