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

[Torsten Lodderstedt <[e-mail]>]

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:
> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth