Token Recipient Confusion
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).