Thanks for this thoughtful analysis, Aaron. I believe you’re spot on that
these attacks can occur “when the attacker has access to both the authorization
code as well as the PKCE code verifier.”
-- Mike
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Aaron Parecki
Sent: Thursday, December 2, 2021 2:58 PM
To: Warren Parad <wparad=40rhosys...@dmarc.ietf.org>
Cc: Pieter Kasselman <pieter.kasselman=40microsoft....@dmarc.ietf.org>;
oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter
Hi all, I've been giving this some more thought.
The problem occurs when the attacker has access to both the authorization code
as well as the PKCE code verifier. The assumption being made with PKCE is that
the first time the PKCE code verifier and authorization code are seen together
is in the POST request to the token endpoint. That means if there is a way to
observe this request, the attacker can complete the exchange and get an access
token.
Pieter's writeup in the PDF describes one way that can happen, by exfiltrating
log files. While I still agree with the sentiment in this thread that this is a
relatively obscure condition, I also agree that it is actually something that
can happen in the wild, especially since there are entire companies built
around the idea of real-time log file analysis.
That said, there are other ways an attacker could get access to these two
pieces of information. What are the different points in a request lifecycle
that could be attacked? The beginning, the middle and the end. We've talked
about attacking the end, which is the log file example. Attacking the middle
involves being in the middle of the TLS connection, which we also know is
possible with corporate network proxies and such. We haven't yet talked about
the beginning of the request. What can observe the beginning of a request?
Here's a concrete example:
Assume the OAuth client is a single-page app in a browser. The user is using an
ad blocker installed as a browser extension. The ad blocker can be configured
to observe and block network requests before they are made. If the extension is
configured to attack a particular OAuth server, the JS client would make the
token request containing the authorization code and PKCE code verifier, then
the extension would be able to observe that request, block it, and ship the two
values to the attacker's server where they can be redeemed and associated with
the attacker's own DPoP key. Even perfectly single-use authorization codes
don't help here either, because the original request was completely blocked.
(Sidenote: To get ahead of any counterarguments here, yes, Chrome is eventually
migrating to their new "manifest v3" which deprecates the webRequest API that
allows this observation in favor of a different API that lets the browser block
requests without making the actual request data available to the extension,
which I am assuming they are doing in no small part because of the possibility
of what I just described. It sounds like Mozilla is going to follow suit, but I
haven't found concrete confirmation of that. That said, it will be a while
before these changes are rolled out and support for the (dangerous) webRequest
API is fully dropped, so this is likely going to continue to be a potential
attack vector for a few years at least.)
Because of the ease of deployment of a malicious browser extension, I do
believe this is an important attack vector to consider and is worth solving. I
am going to save any judgment on the particular dpop_jwk parameter proposal for
a different thread, but I wanted to at least get on the same page about the
fact that this is something worth solving first.
Aaron
On Thu, Dec 2, 2021 at 10:38 AM Warren Parad
<wparad=40rhosys...@dmarc.ietf.org<mailto:40rhosys...@dmarc.ietf.org>> wrote:
The only mention of sophistication is this logical fallacy:
If this leading security company had been penetrated, it almost certainly took
an incredibly sophisticated attack.
But it leaves out exactly what that was. And it doesn't give any insight into
how this attack at MS would have been prevented despite the supply chain
vulnerability based on the second point that Aaron made. If they are able to
get the auth code, why aren't they able to get the DPoP signature? And then
send both of these?
Further in this case, it doesn't even matter if the attacker gets the access
token if that access token is bound to the client, because it's worthless
without the DPoP key. That's a much more secure solution than issuing non-bound
Bearer tokens as a response to the bound authorization code. And if Bearer
tokens are being used instead of bound tokens, then those could still end up in
the logs, and be exfiltrated.
In OAuth, the client already needs to authenticate with the AS, the spec is
SHOULD, and options the client_secret already. Adding in the DPoP signature
into the request is duplicating auth. If we don't like the client auth
mechanisms to the AS, we should directly provide an auth RFC recommending
better alternatives than sending a symmetric client_secret back to the AS.
[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress<https://authress.io/>.
On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman
<pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>
wrote:
Thanks for the comments and engagement Warren.
The attacks we described and the ideas on mitigations are born out of attack
vectors we are observing in the wild. They are not negligible. We are seeing a
new class of very sophisticated attackers, and if you’re interested, this
article provides good context on capability and sophistication of the attackers
Brad Smith: Inside Microsoft during the SolarWinds hack
(fastcompany.com)<https://www.fastcompany.com/90672384/microsoft-president-brad-smith-solarwinds-exclusive>.
We are sharing this with the hope that the industry will benefit from our
experiences and incorporate it into standards and products. Attacks that seemed
impossibly complex are not only possible, but have become probable.
The proposed changes for DPoP are not meant to replace the need for one-time
use tokens (single use tokens are preferable and we should continue to expect
them), but instead address the limitations around implementing one-time use,
especially at scale. The 60s window you mention below is sufficiently long to
be exploited by these sophisticated attackers.
Cheers
Pieter
From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf
Of Warren Parad
Sent: Wednesday 1 December 2021 15:29
To: Pieter Kasselman
<pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>
Cc: Mike Jones
<Michael.Jones=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>;
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter
(e.g. one-time use in a certain timeframe etc).
Sure but couldn't we just reduce the lifetime? Even if the token isn't one time
use, surely the reuse time is trivially short which would prevent against
exfiltration of the necessary security tokens to issue the attack?
I feel like the simpler solution will always win, which in this case is
one-time use tokens, then the problem is moot, right? So this only comes into
play if you want to allow token reuse in a time window. The previously
suggested max allowed time window from OAuth 2.1 was 60s for auth codes. So we
are saying that the attack surface is still too large, for the .01% of
implementations that have multi-use tokens, and the .01% of implementations
that use the maximum 60s reuse, and then the subset of those that aren't
correctly scrubing their logs, and then the subset of those that have a
vulnerability which allows for exfiltration of both those logged tokens and the
logged PKCE verifier?
Why are we making this more complicated for a majority of cases, which:
* Only have single use tokens
* Or Only have a very short lifetime
* Or Are already correctly sanitizing their logs
* Or Have defense in depth for their deployments.
If the implementation is so insecure that none of those are happening, wouldn't
the implementation for this functionality also be suspect for an opportunity
for attack?
I feel like we are justifying here that multi-use tokens are wrong, but still
want a solution to use them. Once we've proven that an deployment is not okay
with using multi-use tokens, then the conclusion should be "don't have
multi-use tokens", not: "let's still have multi-use tokens, but come up with a
complex way to prevent their multi-use from accidentally being abused".
Or am I missing something that would actually make this a non-negligible attack
vector?
- Warren
[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FBkvuWZ3FVTcdTtfe%2FoLurIGxcsJHCz6zXmW1PROTSc%3D&reserved=0>.
On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman
<pieter.kasselman=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>
wrote:
Hi Aaron, Neil
Thanks for the questions.
We agree that ideally authorization codes and PKCE proofs would never end up in
log files and one-time use would be perfectly implemented.
However, in practice these artefacts do find their way into log files in
various places and one-time use may not always be practical (e.g. one-time use
in a certain timeframe etc).
The addition of these mitigations is not meant to replace the need for one-time
use or good logging hygiene. Instead they provide pragmatic defence in depth
against real attacks rather than assuming perfect implementations. We are
deploying these mitigations and are sharing them for inclusion in DPoP to
enable others to do the same.
Regarding the question about interrupting/intercepting the HTTPS connection,
the attacker don’t need to intercept the HTTPS connection or modify the content
in the TLS tunnel, rather they just need to prevent the authorization code from
being presented to the Authorization Server. It may even happen due to a poor
network connection. The poor connection may be engineered by an attacker, or
they may opportunistically benefit from it. The networks are not perfect either.
Cheers
Pieter
From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf
Of Aaron Parecki
Sent: Wednesday 1 December 2021 00:05
To: Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>>
Cc: Mike Jones
<Michael.Jones=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>>;
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter
I tend to agree with Neil here. I'm struggling to see the relevance of this
attack.
It seems like the PDF writeup describes two possible reasons an attacker could
get access to the authorization code and PKCE code verifier.
1. The attacker has access to the logs of the token endpoint.
2. The attacker can intercept HTTPS connections between the client and AS (VPN,
corporate network proxy, etc)
For 1, the solution is to stop logging the contents of the POST body, and
secure your infrastructure. I don't think making the client jump through extra
hoops is a good solution if you are already logging more than you should be or
you don't trust the people who have access to the infrastructure. If this
really is a concern, I suspect there are a lot more places in the flow that
would need to be patched up if you don't trust your own token endpoint.
For 2, if the attacker can intercept the HTTPS connection, then the proposed
solution doesn't add anything because the attacker could modify the requests
before it hits the authorization server anyway, and change which DPoP key the
token gets bound to in the first place. Plus, the attacker would also have
access to anything else the client is sending to the AS, such as the user's
password when they authenticate at the AS.
Are there other attack vectors I'm missing that might actually be solved by
this mechanism?
Aaron
On Tue, Nov 30, 2021 at 12:40 PM Neil Madden
<neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>> wrote:
Sadly I couldn’t make the DPoP session, but I’m not convinced the attack
described in the earlier message really needs to be prevented at all. The
attack largely hinges on auth codes not being one-time use, which is not a good
idea, or otherwise on poor network security on the token endpoint. I’m not
convinced DPoP needs to protect against these things. Is there more to this?
The proposed solutions also seem susceptible to the same problems they attempt
to solve - if an attacker is somehow able to interrupt the client’s
(TLS-protected) token request, why are they somehow not able to
interrupt/modify the (far less protected) redirect to the authorization
endpoint?
— Neil
On 30 Nov 2021, at 20:15, Mike Jones
<Michael.Jones=40microsoft....@dmarc.ietf.org<mailto:Michael.Jones=40microsoft....@dmarc.ietf.org>>
wrote:
As described during the OAuth Security Workshop session on DPoP, I created a
pull request adding the dpop_jkt authorization request parameter to use for
binding the authorization code to the client’s DPoP key.
Seehttps://github.com/danielfett/draft-dpop/pull/89<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F89&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ASCRFFPMA7qIItkxpVTrVaJtC53R2niWOzB0l0GQKrw%3D&reserved=0>.
This is an alternative to
https://github.com/danielfett/draft-dpop/pull/86<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielfett%2Fdraft-dpop%2Fpull%2F86&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lgb9WmnOwWVtNIFsZ1mQG4jSBQYLZv%2BETe6HIKFeerg%3D&reserved=0>,
which achieved this binding using a new DPoP PKCE method. Using this
alternative allows PKCE implementations to be unmodified, while adding DPoP in
new code, which may be an advantage in some deployments.
Please review and comment. Note that I plan to add more of the attack
description written by Pieter Kasselman to the security considerations in a
future commit. This attack description was sent by Pieter yesterday in a
message with the subject “Authorization Code Log File Attack (was DPoP Interim
Meeting Minutes)”.
-- Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vuBY0pdcSiMXQF213ZVLm4yNMFhRqM1jWlrWSzn%2FS%2FE%3D&reserved=0>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vuBY0pdcSiMXQF213ZVLm4yNMFhRqM1jWlrWSzn%2FS%2FE%3D&reserved=0>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vuBY0pdcSiMXQF213ZVLm4yNMFhRqM1jWlrWSzn%2FS%2FE%3D&reserved=0>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
