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

Nat Sakimura <sakimura@gmail.com> Tue, 09 February 2016 03:23 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85981A00F4 for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2016 19:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72H56pJmTpN4 for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2016 19:23:48 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C631A00F3 for <oauth@ietf.org>; Mon, 8 Feb 2016 19:23:48 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id o6so66563541qkc.2 for <oauth@ietf.org>; Mon, 08 Feb 2016 19:23:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=kBT7uI3hVfmBGCsgTL/CiRLcxPAh5T94DmsEScScl+8=; b=KAKEwSIzksVT+4UCe0VTCP71F3E8OWSj+Y9ttmtEzUUU409PjS/GBvXLLtW0rBDuA6 9o/jUtcJvlDq5lhLIJDMeMj+CoBjChwZFEXHCQw1cPT+hFaH5GDL2g626hh4SnjA5Nml O9/jLkuno3mrH89MHZYRukzsSulqRX+TMNfnNuGnwDBWUlliXn6SAHmJvJdlExIeHQGQ XM9qj0kWd3FLpzILDzuV/2C75tiSmHTj7J47DUPgKt1v9dyR5Ox8TJk5OwCnmZtWKKID d9zdH7yAE1hnRdEdinBQUNVonaSok7NVfmNK/A59QO4bNiWy3NW+PLZNzWAaeGyP+urz OPvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=kBT7uI3hVfmBGCsgTL/CiRLcxPAh5T94DmsEScScl+8=; b=WOyPYanlOtIfFrYjV2f0Pn/LOyZemn9qoIuX7+XUlyf3V4KvAYvmLZJLR07bVk+vFx KhpAOL0MQpxYqunettAP2Z7aJ7YsZKceduKSr7aPK8hswND1NTEv4Y3wPGecon8ZuyME qzNY6z1zGS/6XySALcRcIonJCFFV7PWIzLo1Xd+7UTkxwlsZN/mpp7zdYE/xVlwLArFM kletkTuKbI4ZL9FEcxERwXQxJA4TvNt0pqbPpnAcRE64Eyt0+xT2cQIQQ4qe/QF2+BL3 ybMPvHfEHsxayFqvsb9t+WqqxGKTKXOjZxqf9epabUHuNlNnMqmsgR2CiStBX5SwYRkH JN6Q==
X-Gm-Message-State: AG10YOR8VXqzT+vSzsIcojbK16kIPxcmOhGmvZLEAfGDkw9uxrrhyygd6lc8KQHWevl/2yeaZbmgbucFTohxIw==
X-Received: by 10.55.71.66 with SMTP id u63mr38305011qka.67.1454988227517; Mon, 08 Feb 2016 19:23:47 -0800 (PST)
MIME-Version: 1.0
References: <56B3B425.1020701@gmx.net> <56B5D9D5.10102@lodderstedt.net> <822E0CD1-8B49-49DD-80C2-82CD0B5CDC19@ve7jtb.com>
In-Reply-To: <822E0CD1-8B49-49DD-80C2-82CD0B5CDC19@ve7jtb.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Tue, 09 Feb 2016 03:23:37 +0000
Message-ID: <CABzCy2D1uRROaf8FdXW=yMhw_bQ+y_jRsRM=y_UOjcfiH+kCeQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=001a114a797474247b052b4dd8c4
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/FwrktM1-WyBLxxeqsQ7_eAT6Yuc>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2016 03:23:52 -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 <ve7jtb@ve7jtb.com>om>:

> 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 <torsten@lodderstedt.net>
> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>