Re: [OAUTH-WG] Adding the option to use server-supplied nonces to DPoP

[Justin Richer <[e-mail]>]

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 <https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html>

The generic HTTP Message Signatures draft already includes a “nonce” 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.html#section-2.3.1-4.3 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-06.html#section-2.3.1-4.3>

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

However, I’m 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’t 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?

 — Justin

> On Sep 17, 2021, at 1:03 PM, Mike Jones <Michael.Jones=[e-mail]> 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’s 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’s 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’t 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 – 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/ <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.
>  
> ====
>  
> 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) <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517021183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nwnf6O67xIXO2u0cYFkZBnJrnOl0P6JR1MrXdNLgrr8%3D&reserved=0>
> 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) <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517021183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wlEfBuS%2FnIl9qIf51hpQcU2UmFCsnuC0ksSVE%2FXdEKw%3D&reserved=0>
> 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517031142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9rMI1ay6eJ4RmTRTmHglAunMiQuLfxzZUpdk%2F012Z9Q%3D&reserved=0>
> 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fposts.specterops.io%2Frequesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517031142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OLHm5HkOAQZs0uE95OtlvUxRQlk06ylecU09%2B2hacOw%3D&reserved=0>
> 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkjanm.io%2Fabusing-azure-ad-sso-with-the-primary-refresh-token%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517031142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J8rcX59vjyaVlvhdzDBM%2FUELF38LEykzo84an9opNc4%3D&reserved=0>
> 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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdirkjanm.io%2Fdigging-further-into-the-primary-refresh-token%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cd16075338fd34e6065fa08d96f18c785%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637662974517041097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zfgTacWTD38btnIwrPWEStjIIYNfw9tRzjjP95S8gwI%3D&reserved=0>
> Describes how the PRT and session keys can be extracted from a device (requires local admin)
> Operationalised through ROADtools 
>                                                        -- Mike
>  
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>