Re: [OAUTH-WG] DPoP: Threat Model

[Denis]

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:

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


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  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  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.


Am 04.05.20 um 20:06 schrieb Denis:
As soon as a software solution would be available to perform this 
collaborative attack, everybody would be able to 

Re: [OAUTH-WG] DPoP: Threat Model

[Philippe De Ryck]

On 4 May 2020, at 21:44, Daniel Fett  wrote:
> 
> Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>> 
 (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.
> 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.
> 
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___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>
>>> (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.
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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Philippe De Ryck]

>> (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 


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 >> > 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 
>>> 
>>> Can you come up with other attacks? Are the attacks shown relevant?
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>> 
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

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 > > 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
>>
>> Can you come up with other attacks? Are the attacks shown relevant?
>>
>> Cheers,
>> Daniel
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

Hi Denis,

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

Am 04.05.20 um 20:06 schrieb Denis:
> As soon as a software solution would be available to perform this
> collaborative attack, everybody would be able to use it.

Teamviewer is sufficient and widely available.

-Daniel


> 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:
>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
>>
>> Can you come up with other attacks? Are the attacks shown relevant?
>>
>> Cheers,
>> Daniel
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Denis]

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:

https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html

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

Cheers,
Daniel


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Neil Madden]

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 
) 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  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 
> 
> Can you come up with other attacks? Are the attacks shown relevant?
> 
> Cheers,
> Daniel
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] DPoP: Threat Model

[Daniel Fett]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth