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.

This attack also targets the SSO Verificator, which is responsible for checking the restrictions regarding the destination of the token, D. In the SAML context, specifically the AudienceRestricton and Recipient elements are relevant for this attack type.

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.

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

To mitigate the TRC attack, the SP should verify whether the D_A. SP parameter contained in t matches its own D_A.

Practical Attack Examples

In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Zendesk, Clarizen, SAManage, Shiftplanning, Panorama9, UserVoice (Marketing), Instructure, The Resumator, BambooHR, AppDynamics, Panopto, TimeOffManager, HappyFox, ScreenSteps Live, LiveHive, Howlr and CA Service Management. Category:Attack_Categorisation_By_Attack_Spreading hinzufügen!

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).
CVE-2008-3891