Subject: [OAUTH-WG] DPoP: Threat Model

From: Daniel Fett <[email-masked]>
Date: Mon, 4 May 2020 19:24:30 +0200

Hi all,

as mentioned in the WG interim meeting, there are several ideas floating
around of what DPoP actually does.

In an attempt to clarify this, if have unfolded the use cases that I see
and written them down in the form of attacks that DPoP defends against:
https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

Can you come up with other attacks? Are the attacks shown relevant?

Cheers,
Daniel

---

From: Neil Madden <[email-masked]>
Date: Mon, 4 May 2020 18:54:21 +0100

I mentioned another one in my recent email - BREACH attacks against HTTP compression being used to steal access tokens in transit.

There’s a variant of the online XSS attacks in which the attacker just proxies requests through the victim’s browser (https://beefproject.com <https://beefproject.com/>) rather than exfiltrating tokens/proofs. You can protect against exfiltration attacks by e.g. token binding the DPoP proofs and/or access token, or storing the access token in a HttpOnly cookie (gasp!). You can protect against exfiltrating post-dated DPoP proofs by storing the private key in a separate origin loaded in an iframe that you use postMessage to ask for proof tokens so the attacker is not in control of those claims. Nothing really protects against an attacker proxying requests through your browser, so this is purely post-compromise recovery rather than an actual defence against XSS.

— Neil

> On 4 May 2020, at 18:24, Daniel Fett <[email-masked]> wrote:
> 
> Hi all,
> 
> as mentioned in the WG interim meeting, there are several ideas floating around of what DPoP actually does.
> 
> In an attempt to clarify this, if have unfolded the use cases that I see and written them down in the form of attacks that DPoP defends against: 
> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html <https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Mon, 4 May 2020 20:06:39 +0200

Hi Daniel,

Yes indeed. For another attack, please see my email sent to the list on 
01/05/2020 at 10:47 (Paris time).
The subject was: DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks.

When the JWT does not contain a sufficient number of attributes that 
would allow to identify the user,
the collaborative user can transmit it to anybody else, without the risk 
to be detected by the RS.  E.g. it
only contains the age of the user and a membership to a large group of 
people.

When the JWT contains attributes that uniquely allow to identify the 
collaborative user, then the other client
will be in a position to impersonate the collaborative user. Some users 
may not accept to be impersonated
by anybody and thus will only be collaborative with some trusted friends.

This collaborative attack would be much simpler to accomplish than the 
four types of attacks that have been described.
As soon as a software solution would be available to perform this 
collaborative attack, everybody would be able to use it.

Denis

> Hi all,
>
> as mentioned in the WG interim meeting, there are several ideas 
> floating around of what DPoP actually does.
>
> In an attempt to clarify this, if have unfolded the use cases that I 
> see and written them down in the form of attacks that DPoP defends 
> against:

---

From: Daniel Fett <[email-masked]>
Date: Mon, 4 May 2020 21:02:50 +0200

Hi Denis,

We discussed these kinds of collusion attacks at great length previously
on this list. My views on them have not changed.

> collaborative attack, everybody would be able to use it.

Teamviewer is sufficient and widely available.

-Daniel

---

From: Daniel Fett <[email-masked]>
Date: Mon, 4 May 2020 21:16:23 +0200

Am 04.05.20 um 19:54 schrieb Neil Madden:
> I mentioned another one in my recent email - BREACH attacks against
> HTTP compression being used to steal access tokens in transit.
Excellent point, I added that one.
>
> There’s a variant of the online XSS attacks in which the attacker just
> proxies requests through the victim’s browser

That was the attack that should have been described under "Online XSS"
in the first place. I somehow got confused along the way. Exfiltration
of precomputed values is definitely /not/ "Online XSS".

> (https://beefproject.com) rather than exfiltrating tokens/proofs.

As a sidenote: BeEF is not really XSS but requires a full browser
compromise.

Thanks for the feedback!

-Daniel

> You can protect against exfiltration attacks by e.g. token binding the
> DPoP proofs and/or access token, or storing the access token in a
> HttpOnly cookie (gasp!). You can protect against exfiltrating
> post-dated DPoP proofs by storing the private key in a separate origin
> loaded in an iframe that you use postMessage to ask for proof tokens
> so the attacker is not in control of those claims. Nothing really
> protects against an attacker proxying requests through your browser,
> so this is purely post-compromise recovery rather than an actual
> defence against XSS.
>
> — Neil
>
>> On 4 May 2020, at 18:24, Daniel Fett <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Philippe De Ryck <[email-masked]>
Date: Mon, 4 May 2020 21:27:42 +0200

>> (https://beefproject.com <https://beefproject.com/>) rather than exfiltrating tokens/proofs.
> As a sidenote: BeEF is not really XSS but requires a full browser compromise.
> 

No, it’s not. The hook for BeEF is a single JS file, containing a wide variety of attack payloads that can be launched from the command and control center. You can combine BeEF with Metasploit to leverage an XSS to exploit browser vulnerabilities and break out.

FYI, the name for the attack where the attacker proxies calls through the user’s browser is known as Session Riding. 

Just keep in mind that once an attacker has an XSS foothold, it is extremely hard to prevent abuse. The only barrier that cannot be broken (in a secure browser) is the Same Origin Policy. Keeping tokens and metadata in a separate environment (e.g., iframe, worker, …) is effective to keep them out of reach. However, once the app “extracts” data from such a context, the same problem arises. By rewriting JS functions, the attacker can extract tokens from deep within an SDK, as I discuss here: https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html <https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html>

Kind regards

Philippe
> Thanks for the feedback!
> 
> -Daniel
> 
> 
> 
>> You can protect against exfiltration attacks by e.g. token binding the DPoP proofs and/or access token, or storing the access token in a HttpOnly cookie (gasp!). You can protect against exfiltrating post-dated DPoP proofs by storing the private key in a separate origin loaded in an iframe that you use postMessage to ask for proof tokens so the attacker is not in control of those claims. Nothing really protects against an attacker proxying requests through your browser, so this is purely post-compromise recovery rather than an actual defence against XSS.
>> 
>> — Neil
>> 
>>> On 4 May 2020, at 18:24, Daniel Fett <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi all,
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>

---

From: Daniel Fett <[email-masked]>
Date: Mon, 4 May 2020 21:44:52 +0200

Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
> No, it’s not. The hook for BeEF is a single JS file, containing a wide
> variety of attack payloads that can be launched from the command and
> control center. You can combine BeEF with Metasploit to leverage an
> XSS to exploit browser vulnerabilities and break out.
I shall stand corrected!
>
> Just keep in mind that once an attacker has an XSS foothold, it is
> extremely hard to prevent abuse. The only barrier that cannot be
> broken (in a secure browser) is the Same Origin Policy. Keeping tokens
> and metadata in a separate environment (e.g., iframe, worker, …) is
> effective to keep them out of reach. However, once the app “extracts”
> data from such a context, the same problem arises.

Compartmentalization within an origin is as old a problem as it is
mostly unsolved, indeed. That is why I would not further differentiate
in case the browser is online and the client's script is compromised,
but instead assume that the attacker can then forge arbitrary requests
using the token.

-Daniel

---

From: Philippe De Ryck <[email-masked]>
Date: Mon, 4 May 2020 21:48:49 +0200

On 4 May 2020, at 21:44, Daniel Fett <[email-masked]> wrote:
>> Just keep in mind that once an attacker has an XSS foothold, it is extremely hard to prevent abuse. The only barrier that cannot be broken (in a secure browser) is the Same Origin Policy. Keeping tokens and metadata in a separate environment (e.g., iframe, worker, …) is effective to keep them out of reach. However, once the app “extracts” data from such a context, the same problem arises. 
> Compartmentalization within an origin is as old a problem as it is mostly unsolved, indeed. That is why I would not further differentiate in case the browser is online and the client's script is compromised, but instead assume that the attacker can then forge arbitrary requests using the token.
> 
I agree on that assumption. The moment malicious script executes, it’s game over, regardless of the specifics on whether a token can be extracted or not. Even with isolation, an attacker would be able to trick the isolated context in making requests as a confused deputy.

Philippe

---

From: Denis <[email-masked]>
Date: Tue, 5 May 2020 17:15:08 +0200

Hi Daniel,

Rather than answering between the lines, I place a global answer in 
front of your message.

Depending upon the content of the JWT, two different collaborative 
attacks need to be considered,
one of them being an impersonation attack which can indeed be performed 
using Teamviewer.

The other one, i.e. when the JWT does not contain a set of attributes 
that is sufficient to identify an individual,
is not and cannot be performed using Teamviewer because it does not deal 
with impersonation.

Let us consider a scenario to illustrate this second case.

Alice is Client A while Bob is Client B.

Alice and Bob have both opened an account on a web server allowing to 
make reservations on tennis courts managed by the town of Utopia.

Bob is a resident from Utopia, but Alice is not. Residents from Utopia 
are allowed to perform tennis courts reservations two weeks in advance
while other people can only perform them 48 hours in advance.

An Attribute Server (AS) managed by the town of Utopia is able to 
provide a JWT stating that the holder is indeed a resident of Utopia
(there are about 50.000 residents). The holder can use such a JWT for 
different web sites: library, swimming pool, tennis, ... The web servers
trusting the AS from the town of Utopia ask to present such a JWT once a 
year which may allow to get some advantages during one year.

Bob has already presented such a JWT at the beginning of the year, thus 
he can enjoy making tennis courts reservations two weeks in advance.
Alice is annoyed since most of the time 48 hours ahead, most tennis 
courts are already reserved. So she asks Bob whether he would accept
to request a new JWT token stating that the holder is indeed a resident 
of Utopia. Let us assume that Bob accepts.

When Alice connects to the server, she also ask Bob to connect to the AS 
and to provide her with the JWT and to stay online to perform
all the cryptographic computations she will need to present this JWT to 
the tennis courts web server. For doing this, they both use
a specific piece of software developed for this purpose.

When this is done, during one year, Alice will enjoy to make tennis 
reservations two weeks in advance. At this end of these 12 months,
she will ask Bob to collaborate again.

In this scenario, unless the AS and the RS collaborate, nobody will know 
that Alice and Bob collaborated.

You wrote:

You are not saying in this email what your views are. However, I browsed 
through the last exchanged emails.

On November 8, 2019, under the thread "WGLC for "OAuth 2.0 Security Best 
Current Practice", you wrote:

I have the feeling that this attack aims at breaking a security property 
that OAuth does not claim to fulfill (and that nobody expects OAuth to 
fulfill):

      (...)

      And there are good reasons why this is not captured by the 
security property (Hans' screenshot, for example).

     As far as I know, this property is neither achieved by classical 
first-party session-based authentication/authorization nor by any other 
web-based mechanism, or is it?

I responded to this email:
*
Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
*Denis <[email-masked]> Tue, 12 November 2019 09:19 UTC
https://mailarchive.ietf.org/arch/msg/oauth/Gc8T8mRkF5vJT7fV3uSc66B_9Fs/

However, you never responded to it. Up to now, I don't know what "Hans' 
screenshot" was and I don't know the "good reasons
why this is not captured by the security property".

On November 13, I sent an email to the list and to Brian:
*
Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-fett-oauth-dpop-03.txt
*Denis <[email-masked]> Wed, 13 November 2019 09:17 UTC
https://mailarchive.ietf.org/arch/msg/oauth/WC8jCC-U3bAhlBHEVRLAdSOuY98/

At the end, I wrote:

     DPoP is not able to counter collusion attacks between clients and 
this should be clearly advertised in the abstract, in the main 
objectives (section 2)
     and in the security considerations (section 9).

You have not participated to this thread. However, DPoP is still silent 
about this kind of attack.

RFC 3552 (Security Considerations Guidelines) states in its Introduction :

     "All RFCs are required by RFC 2223 to contain a Security 
Considerations section.The purpose of this is both
      to encourage document authors to consider security in their 
designs and to _inform the reader of relevant security issues_".

draft-fett-oauth-dpop does not comply with RFC 3552 but it should.

Denis

P.S. It is possible to counter the Alice and Bob collusion attack (ABC 
attack) when specific secure elements are being used.

> Hi Denis,
>
> We discussed these kinds of collusion attacks at great length 
> previously on this list. My views on them have not changed.
>