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

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>:

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