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...")
 
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Attack description=
=Introduction=
In real-life SSO, there exist multiple ''Software-as-a-Service Cloud Provider (SaaS-CP)'' federating with the same ''Identity Provider (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.
According to [http://www.cvedetails.com/cve/CVE-2008-3891], this type of attacks is classified as critical, since information disclosure or privilege escalation is possible. A dishonest user can redeem his tokens on different services and get unauthorized access to restricted resources. Furthermore, a malicious ''SaaS-CP'' could collect authentication tokens and forward them to other SPs in order to get login in arbitrary accounts.
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.




=Attack subtypes=
=Attack subtypes=
There are no attack subtypes for this attack.


=Prerequisites=
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''.


=Prerequisites for attack=
=Target=
[[File:Target_Verificator.jpg|centre|600px]]
The attacked Single Sign-On component is marked in red colour.


=Description=
There are two different approaches for a ''TRC'' exploit: <br>
'''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.


=Graphical representation of attack=
'''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'''.


[[File:Token_Recipient_Confusion.jpg|centre]] <br>
SAML token addressed for service '''S_A''' will be sent to '''S_target'''.


=Attack example=
=Mitigation / Countermeasures=
To mitigate the TRC attack, the SP should verify whether the '''D_A'''. SP parameter contained in '''t_A''' matches its own '''D_A'''. In terms of SAML this means, that '''S_target''' needs to verify the URL in the conditions ''AudienceRestricton'' and ''Recipient'' elements to match its own URL.


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


=Attack mitigation / countermeasures=
=Practical Attack Examples=


[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Availability]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Integrity]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]


=References=
=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).
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).<br>
[http://www.cvedetails.com/cve/CVE-2008-3891 CVE-2008-3891] <br>
[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf Security Assertion Markup Language (SAML) V2.0 Technical Overview]

Latest revision as of 19:09, 26 January 2016

Introduction

In real-life SSO, there exist multiple Software-as-a-Service Cloud Provider (SaaS-CP) federating with the same Identity Provider (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. According to [1], this type of attacks is classified as critical, since information disclosure or privilege escalation is possible. A dishonest user can redeem his tokens on different services and get unauthorized access to restricted resources. Furthermore, a malicious SaaS-CP could collect authentication tokens and forward them to other SPs in order to get login in arbitrary accounts. 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.


Attack subtypes

There are no attack subtypes for this attack.

Prerequisites

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.

Target

The attacked Single Sign-On component is marked in red colour.

Description

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.


SAML token addressed for service S_A will be sent to S_target.

Mitigation / Countermeasures

To mitigate the TRC attack, the SP should verify whether the D_A. SP parameter contained in t_A matches its own D_A. In terms of SAML this means, that S_target needs to verify the URL in the conditions AudienceRestricton and Recipient elements to match its own URL.

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

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
Security Assertion Markup Language (SAML) V2.0 Technical Overview