Hi Pedram, Thanks for confirming that the scenario is as I was trying to understand it. I don't think it's universal that all clients will give transitive access from the user to the accessed resource, though it's certainly common; the lack of exposition on that point is what I had been stumbling on.
-Ben On Tue, Nov 26, 2019 at 06:33:04PM +0100, Pedram Hosseyni wrote: > Hi Ben, > > The attacker uses the (honest) client shown in Figure 4 as a regular > user. For example, the client might provide access to a cloud storage > via its website, i.e., by using the clients' website, a user can access > her files stored at the resource server. > > I'll try to clarify the attack with a simplified example. > > Let's assume that the client supports two authorization servers > AS_honest and AS_attacker. Intuitively, if the attacker phishes an > access token created by AS_honest for an honest user (Alice), one would > expect that sender-constraining the access token (e.g., via mTLS) > prevents the attacker from using this access token. > > The overall goal of the attacker is to use the sender-constrained access > token (which he cannot use directly at the resource server) to access > Alices cloud storage. > > The attack works as follows: > > First, the attacker visits the website of the client. Usually, the > attacker would now choose an AS, and after successful authentication, > access his files stored in the cloud. When selecting the AS, the > attacker chooses AS_attacker. In Step 5 of Figure 4, AS_attacker now > provides the phished access token. As this token is bound to this > client, the client can use it at the resource server for getting access > to the cloud storage of Alice. As the attacker is using the client > (through the clients' website), he now gets access to these files > (stored at the RS). > > Please let me know if you have any other questions. > > Best regards, > Pedram > > > On 26.11.19 16:51, Benjamin Kaduk wrote: > > Hi Pedram, > > > > On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote: > >> Also, for this or the next version of this document, the Cuckoo's Token > >> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should > >> be addressed. We also discussed this issue extensively at the last OSW > >> in Stuttgart. > > I took a look at the paper, and I'm not sure I'm properly understanding the > > "Cuckoo's Token" attack. Looking at Figure 4 of the paper to have > > something concrete to refer to, I assume that the client, as a white box, > > is presumed to be honest. Since the access token is bound to the client, I > > assume that the attacker has to return the phished access token to the same > > client that originally (honestly) got it, as otherwise the token will not > > be usable at the RS. The paper concludes that in step 6, the client gets > > access to the honest resource owner's resources, and furthermore that the > > attacker has access to those resources through the client. It's that last > > part that I'm not sure I understand -- if the client is honest, why would > > it return resource information to the attacker? The best I can come up > > with is that there's some sense of a "session" between the user and client, > > such that the client links its resource accesses with the "session" on > > behalf of which the access occurs, and is willing to return such > > information back to the user only on the "linked session". (The > > countermeasure makes sense and is a good practice, of course.) > > > > Thanks, > > > > Ben > > -- > Pedram Hosseyni, M.Sc. > Room V38 2.438 > Institute of Information Security - SEC > Universität Stuttgart > Universitätsstraße 38 > D-70569 Stuttgart > Germany > Phone: +49 711 685 88454 > https://sec.uni-stuttgart.de > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
