Token Recipient Confusion: Difference between revisions

From Single Sign-On Attacks
Jump to navigation Jump to search
(Created page with "=Attack description= =Attack subtypes= =Prerequisites for attack= =Graphical representation of attack= =Attack example= =Attack mitigation / countermeasures= =Prac...")
 
No edit summary
Line 1: Line 1:
=Attack description=
=Attack description=
In real-life SSO, there exist multiple SaaS-CPs federating with the same IdP. In order to distinguish the authentication tokens generated
for different SaaS-CPs, each token contains information ''D'' about its recipient. In most cases this is the URL of the SaaS-CP for which the token was generated.


The goal of ''Token Recipient Confusion (TRC)'' is to use an authentication token ''t_A'' generated for a service ''S_A'' on a second service ''S_target''. The attack is considered successful if ''S_target'' becomes “confused” by the recipient of the token and accepts ''t_A'' as valid.


=Attack subtypes=
=Attack subtypes=
Line 6: Line 9:


=Prerequisites for attack=
=Prerequisites for attack=
 
The attacker has access to a valid token. An additional requirement is that both services ('''S_A''' and '''S_target''') have to be federating with the same IdP. This is a realistic assumption since an IdP usually offers authentication services for multiple SaaS-CPs.


=Graphical representation of attack=
=Graphical representation of attack=
Line 12: Line 15:


=Attack example=
=Attack example=
There are two different approaches for a ''TRC'' exploit:
'''Exploit 1:''' Suppose, that SaaS-CPs '''S_A''' and '''S_target''' are accepting tokens from the same IdP, and the attacker does not have access
to '''S_target'''. The attacker does, however, have legitimate account on '''S_A''', thus, he can request a token '''t_A = (..., D_A, ...)''' from the IdP. By sending ''t_A'' to ''S_target'' (instead of '''S_A'''), the attack is performed. It is considered successful if ''t_A'' is accepted by '''S_target'''; the attacker is thus logged in with the same account name as he has for '''S_A''' and gets access to '''S_target'''’s corresponding resources.
'''Exploit 2:''' Alternatively, the attacker can set up his own SaaS-CP ('''S_bad''') offering some service for registered users (e.g., a weather
forecast). To authenticate to '''S_bad''', SSO is used and the attacker specifically federates it with the same IdP used by '''S_target'''. After
that, the attacker lures his victim (a legitimate user of '''S_target''') to register with and authenticate to '''S_bad'''. Instead of or in addition
to its usual service (weather forecast), '''S_bad''' stores all tokens in a database so that the attacker can access them. The attacker can then
try to use the tokens to log in on '''S_target''' as the victim. The attack is considered successful if an authentication token '''t_bad''' issued for the victim for service '''S_bad''' is successfully verified on '''S_target'''.





Revision as of 15:57, 14 January 2016

Attack description

In real-life SSO, there exist multiple SaaS-CPs federating with the same IdP. In order to distinguish the authentication tokens generated for different SaaS-CPs, each token contains information D about its recipient. In most cases this is the URL of the SaaS-CP for which the token was generated.

The goal of Token Recipient Confusion (TRC) is to use an authentication token t_A generated for a service S_A on a second service S_target. The attack is considered successful if S_target becomes “confused” by the recipient of the token and accepts t_A as valid.

Attack subtypes

Prerequisites for attack

The attacker has access to a valid token. An additional requirement is that both services (S_A and S_target) have to be federating with the same IdP. This is a realistic assumption since an IdP usually offers authentication services for multiple SaaS-CPs.

Graphical representation of attack

Attack example

There are two different approaches for a TRC exploit:

Exploit 1: Suppose, that SaaS-CPs S_A and S_target are accepting tokens from the same IdP, and the attacker does not have access to S_target. The attacker does, however, have legitimate account on S_A, thus, he can request a token t_A = (..., D_A, ...) from the IdP. By sending t_A to S_target (instead of S_A), the attack is performed. It is considered successful if t_A is accepted by S_target; the attacker is thus logged in with the same account name as he has for S_A and gets access to S_target’s corresponding resources.

Exploit 2: Alternatively, the attacker can set up his own SaaS-CP (S_bad) offering some service for registered users (e.g., a weather forecast). To authenticate to S_bad, SSO is used and the attacker specifically federates it with the same IdP used by S_target. After that, the attacker lures his victim (a legitimate user of S_target) to register with and authenticate to S_bad. Instead of or in addition to its usual service (weather forecast), S_bad stores all tokens in a database so that the attacker can access them. The attacker can then try to use the tokens to log in on S_target as the victim. The attack is considered successful if an authentication token t_bad issued for the victim for service S_bad is successfully verified on S_target.


Attack mitigation / countermeasures

Practical Attack Examples

References

C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).