Signature Exclusion Attack and Token Recipient Confusion: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=Attack description=
=Introduction=
The integrity of all authentication tokens should be protected. In case of [http://www.sso-attacks.org/SAML ''SAML''], this is realized by a digital signature ''s = SIG_IdP(t)''. ''Signature Exclusion'' (0Sig) exploits a vulnerability in the verification logic allowing the usage of unsigned tokens. If SAML token does not contain any signature, no protection of integrity or authenticity is provided. Since no digital signature for the token is required, an attacker can generate tokens containing arbitrary identities ''(I)'' of other users.
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.
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=
In order for this attack to work the attacker has to have knowledge about the following things:
[[File:Target_Verificator.jpg|centre|600px]]
#'''Attacker knows endpoint of the web service.''' otherwise, he is not able to reach the web service.
The attacked Single Sign-On component is marked in red colour.
#'''Attacker knows that the web service processes the security header and the ''"signature"'' element.''' If the web service does not '''"expect"''' an signed part, it just discards the signature and the attack does not work.
 
 
=Graphical representation of attack=
 
[[File:Signature_Exclusion_Attack.jpg|center]]


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


=Attack example=
'''Exploit 2:''' Alternatively, the attacker can set up his own ''SaaS-CP'' ('''S_bad''') offering some service for registered users (e.g., a weather
The attacker creates authentication tokens containing statements about other users ''t = (..., I_Alice/I_Bob/I_Admin,...)''. He then sends the token to an ''Software-as-a-Service Cloud Provider (SaaS-CP)'' (Starget) and is logged in with the corresponding identity. Finally, the attacker gains access to arbitrary accounts and their resources. The attack is targeted at the ''Single Sign-On (SSO)'' Verificator, which should require that the authentication token is signed and verify the applied signature. By this means, the integrity of the authentication token is guaranteed.
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 mitigation / countermeasures=
=Mitigation / Countermeasures=
SAML messages without signature must not be accepted.
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 Attack Examples=
=Practical Examples=
In 2012, Somorovsky et al. applied the Signature Exclusion attack on three SAML frameworks: Apache Axis2, JOSSO and OpenAthens.  
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.


In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Clarizen.


 
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[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_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Application_Logic]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]
[[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.nds.rub.de/research/publications/BreakingSAML/ J. Somorovsky, A. Mayer, J. Schwenk, M. Kampmann, M. Jensen: On Breaking SAML: Be Whoever You Want to Be. In Pro­cee­dings of the 21st USE­NIX Se­cu­ri­ty Sym­po­si­um, 2012.]
[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]

Revision as of 17:46, 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