From nobody Fri Sep 17 13:12:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FB3A1267; Fri, 17 Sep 2021 13:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ERdc1Gc6fN22; Fri, 17 Sep 2021 13:12:26 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BD83A1268; Fri, 17 Sep 2021 13:12:25 -0700 (PDT) Received: from [192.168.1.28] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 18HKCNwV026757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Sep 2021 16:12:23 -0400 From: Justin Richer Message-Id: <033CE24C-C143-4067-AA67-012A41EBB9DD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 17 Sep 2021 16:12:23 -0400 In-Reply-To: Cc: "oauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [OAUTH-WG] Adding the option to use server-supplied nonces to DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2021 20:12:31 -0000 --Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, thanks for this writeup and bringing this attack surface to the = attention of the group! I would like to also discuss how this attack and = solution could be applied to the proposed HTTP Message Signatures based = draft for OAuth 2: https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html = The generic HTTP Message Signatures draft already includes a =E2=80=9Cnonc= e=E2=80=9D parameter that can be used with the signature, so no new = fields need to be defined: = https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-06.h= tml#section-2.3.1-4.3 = However, the OAuth2 application draft doesn=E2=80=99t currently do = anything special with this parameter. If I=E2=80=99m reading this PR for = DPoP and the surrounding issues correctly, then I believe the one = missing piece is adding the `nonce=3D=E2=80=A6` portion to the = `WWW-Authenticate` response header, and requiring the client to use that = on the next request. The OAuth2-httpsig draft doesn=E2=80=99t define a = use of this header, yet, but I could see something similar happening = there. However, I=E2=80=99m also wondering if this is something we should bring = to the HTTP working group and have something in the full HTTP Message = Signatures draft. This draft doesn=E2=80=99t deal with the = `Authorization` or `WWW-Authenticate` headers, but it does define an = `Accept-Signature` header to signal required parameters and signed = components, for exactly this kind of negotiation. The OAuth2-httpsig = draft could simply direct the AS/RS to return this `Accept-Signature` = header with a nonce field in order to cause the client to sign = subsequent requests using the server-provided nonce. What are your thoughts on these proposals? =E2=80=94 Justin > On Sep 17, 2021, at 1:03 PM, Mike Jones = wrote: >=20 > We all know that using proof-of-possession with issued tokens is a = means of rendering exfiltrated tokens useless to attackers. The DPoP = was created as one of the tools to prevent this. There=E2=80=99s a huge = amount of evidence of successful token exfiltration attacks in the wild, = some of which is referenced at the end of this message. For instance, = sometimes the legitimate user of a client is the attacker. Once = instance of this is that some banks have cited employees stealing = legitimate tokens issued on bank computers and taking them to non-bank = computers, thereby bypassing audit controls. > =20 > When reviewing DPoP with Microsoft=E2=80=99s identity architects, they = pointed out that DPoP as written today can still enable exfiltrated DPoP = tokens to be used by some kinds of attackers; doing so also requires = that the attackers exfiltrate DPoP proofs. This is possible when the = legitimate user of a client is the attacker. > =20 > Preventing exfiltrated pre-generated DPoP proofs from being used in = the future requires the server being able to limit their lifetime. An = effective means of doing this is to include a server-provided nonce in = the DPoP proof. That puts the lifetime of DPoP proofs in control of the = server, because when a new nonce value is provided, older, possibly = pre-generated DPoP proofs become invalid at the server. > =20 > The Microsoft identity server team is already internally using this = technique with the stale OAuth HTTP Signing draft. They want to be able = to use it with DPoP for the same reasons. DPoP without this won=E2=80=99t= mitigate the real security attacks that our systems are encountering. = Note that unless a server-provided nonce is used, what is actually being = proved is possession of a DPoP proof =E2=80=93 not possession of the = proof-of-possession key. > =20 > Having discussed this with some of the editors, I have created a pull = request adding the optional use of server-provided nonces to DPoP. This = will break no existing deployments. But it will enable new deployments = to choose to use server-contributed nonces to limit DPoP proof = lifetimes, both for authorization servers and resource servers. The = pull request is at https://github.com/danielfett/draft-dpop/pull/81/ = . Reviews of the PR = are welcomed. I propose that we merge it and publish draft -04 sometime = next week, pending review feedback. > =20 > =3D=3D=3D=3D > =20 > My colleague Pieter Kasselman assembled some examples of successful = token exfiltration attacks in the public domain (and helped review the = PR). Those follow, for your reading pleasure. > Introducing a new phishing technique for compromising Office 365 = accounts (o365blog.com) = > It describes a phishing attack that allows the attacker to obtain an = Access Token and a Refresh Token (which is then used to obtain = additional Access Tokens). > Operationalised with the AADInternals Tool > The Art of the Device Code Phish - Boku (0xboku.com) = = > It extends the above attack and shows step-by-step how to exfiltrate a = Access Token and a Refresh Token with a similar phishing attack and then = obtain additional tokens. > Operationalised with AADInternals and TokenTactics > DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth = Authentication Flows - YouTube = > It shows another attack to exfiltrate tokens using phishing techniques = that exploit Device Code Flow. > It includes a demo of the attack that shows how it bypasses MFA and = anti-Phishing controls and then uses the PRT to get tokens and pivot to = other services. > Tools available as open source. > Requesting Azure AD Request Tokens on Azure-AD-joined Machines for = Browser SSO | by Lee Christensen | Posts By SpecterOps Team Members = > Outlines how a Refresh Token can be exfiltrated from a Chrome browser > Operationalised with a tool called RequestAADRefreshToken > Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io = > Extracts the Primary Refresh Token through Chrome > Requires executing code on the users device to interact with the = Chrome browser, executed in the user context, no elevated privileges = needed > Operationalised through ROADtoken and ROADtools. > Digging further into the Primary Refresh Token - dirkjanm.io = > Describes how the PRT and session keys can be extracted from a device = (requires local admin) > Operationalised through ROADtools=20 > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mike, thanks for this writeup and bringing this attack surface to the = attention of the group! I would like to also discuss how this attack and = solution could be applied to the proposed HTTP Message Signatures based = draft for OAuth 2:

https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.h= tml

The = generic HTTP Message Signatures draft already includes a =E2=80=9Cnonce=E2= =80=9D parameter that can be used with the signature, so no new fields = need to be defined:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-sign= atures-06.html#section-2.3.1-4.3

However, the OAuth2 application draft = doesn=E2=80=99t currently do anything special with this parameter. If = I=E2=80=99m reading this PR for DPoP and the surrounding issues = correctly, then I believe the one missing piece is adding the = `nonce=3D=E2=80=A6` portion to the `WWW-Authenticate` response header, = and requiring the client to use that on the next request. The = OAuth2-httpsig draft doesn=E2=80=99t define a use of this header, yet, = but I could see something similar happening there.

However, I=E2=80=99m = also wondering if this is something we should bring to the HTTP working = group and have something in the full HTTP Message Signatures draft. This = draft doesn=E2=80=99t deal with the `Authorization` or = `WWW-Authenticate` headers, but it does define an `Accept-Signature` = header to signal required parameters and signed components, for exactly = this kind of negotiation. The OAuth2-httpsig draft could simply direct = the AS/RS to return this `Accept-Signature` header with a nonce field in = order to cause the client to sign subsequent requests using the = server-provided nonce.

What are your thoughts on these proposals?

 =E2=80=94 = Justin

On Sep 17, 2021, at 1:03 PM, Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

We all know that using = proof-of-possession with issued tokens is a means of rendering = exfiltrated tokens useless to attackers.  The DPoP was created as = one of the tools to prevent this.  There=E2=80=99s a huge amount of = evidence of successful token exfiltration attacks in the wild, some of = which is referenced at the end of this message.  For instance, = sometimes the legitimate user of a client is the attacker.  Once = instance of this is that some banks have cited employees stealing = legitimate tokens issued on bank computers and taking them to non-bank = computers, thereby bypassing audit controls.
 
When reviewing DPoP with = Microsoft=E2=80=99s identity architects, they pointed out that DPoP as = written today can still enable exfiltrated DPoP tokens to be used by = some kinds of attackers; doing so also requires that the attackers = exfiltrate DPoP proofs.  This is possible when the legitimate user = of a client is the attacker.
 
Preventing exfiltrated pre-generated DPoP proofs = from being used in the future requires the server being able to limit = their lifetime.  An effective means of doing this is to include a = server-provided nonce in the DPoP proof.  That puts the lifetime of = DPoP proofs in control of the server, because when a new nonce value is = provided, older, possibly pre-generated DPoP proofs become invalid at = the server.
 
The Microsoft identity = server team is already internally using this technique with the stale = OAuth HTTP Signing draft.  They want to be able to use it with DPoP = for the same reasons.  DPoP without this won=E2=80=99t mitigate the = real security attacks that our systems are encountering.  Note that = unless a server-provided nonce is used, what is actually being proved is = possession of a DPoP proof =E2=80=93 not possession of the = proof-of-possession key.
 
Having discussed this with = some of the editors, I have created a pull request adding the optional = use of server-provided nonces to DPoP.  This will break no existing = deployments.  But it will enable new deployments to choose to use = server-contributed nonces to limit DPoP proof lifetimes, both for = authorization servers and resource servers.  The pull request is = at https://github.com/danielfett/draft-dpop/pull/81/.  = Reviews of the PR are welcomed.  I propose that we merge it and = publish draft -04 sometime next week, pending review feedback.
 
=3D=3D=3D=3D
 
My colleague Pieter = Kasselman assembled some examples of successful token exfiltration = attacks in the public domain (and helped review the PR).  Those = follow, for your reading pleasure.
  1. Introducing a new phishing technique for = compromising Office 365 accounts (o365blog.com)
    1. It describes a = phishing attack that allows the attacker to obtain an Access Token and a = Refresh Token (which is then used to obtain additional Access = Tokens).
    2. Operationalised = with the AADInternals Tool
  2. The Art of the Device Code Phish = - Boku (0xboku.com)
    1. It extends the above attack and shows step-by-step how to = exfiltrate a Access Token and a Refresh Token with a similar phishing = attack and then obtain additional tokens.
    2. Operationalised with = AADInternals and TokenTactics
  1. DEF CON 29 - Jenko Hwong - New Phishing Attacks = Exploiting OAuth Authentication Flows - YouTube
    1. It shows = another attack to exfiltrate tokens using phishing techniques that = exploit Device Code Flow.
    2. It includes a demo of the attack that shows how it bypasses = MFA and anti-Phishing controls and then uses the PRT to get tokens and = pivot to other services.
    3. Tools available as open source.
  1. Requesting Azure AD Request Tokens on = Azure-AD-joined Machines for Browser SSO | by Lee Christensen | Posts By = SpecterOps Team Members
    1. Outlines how a Refresh Token can be exfiltrated from a Chrome = browser
    2. Operationalised = with a tool called RequestAADRefreshToken
  1. Abusing Azure AD SSO = with the Primary Refresh Token - dirkjanm.io
    1. Extracts the = Primary Refresh Token through Chrome
    2. Requires executing code on the users device to interact with = the Chrome browser, executed in the user context, no elevated privileges = needed
    3. Operationalised = through ROADtoken and ROADtools.
    Digging further into the = Primary Refresh Token - dirkjanm.io
    1. Describes how = the PRT and session keys can be extracted from a device (requires local = admin)
    2. Operationalised = through ROADtools 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216--