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/. 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. 1. 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 2. 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 1. 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. 1. 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 1. 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. 1. 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
