XML Signature Wrapping 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:
=Introduction=
=Introduction=
The idea of ''XML Signature Wrapping (XSW)'' is to exploit the separation between SSO Verificator and SSO Processor. In case both logics
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
have different "views" of the same document, XSW can be applicable.
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 is to force the SSO Verificator to use different elements than the SSO Processor.  
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 several options to perform Signature Wrapping depending on the implementation of the verification logic:
There are no attack subtypes for this attack.
*[http://ws-attacks.org/XML_Signature_Wrapping_-_Simple_Context Simple Context]
*[http://ws-attacks.org/XML_Signature_Wrapping_-_Optional_Element Optional Element]
*[http://ws-attacks.org/XML_Signature_Wrapping_-_Optional_Element_in_Security_Header Optional Element in Security Header]
*[http://ws-attacks.org/XML_Signature_Wrapping_-_with_Namespace_Injection With Namespace Injection]


=Prerequisites=
=Prerequisites=
The attacker needs access to a valid token. For this attack to work, the attacker modifies the contents of the token by injecting malicious data without invalidating the signature.
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=
=Target=
[[File:Target_Verificator_and_Processor1.jpg|centre|600px]]
[[File:Target_Verificator.jpg|centre|600px]]
<br> The attacked Single Sign-On components are marked in red colour.
The attacked Single Sign-On component is marked in red colour.


The attack targets the discrepancy in the program logic of SSO Verificator and SSO Processor. The latter should extract and forward only exactly the data verified by the former to ''Authorization & Access Management (AAM)''.
=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.


=Description=
'''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 manipulates his token by injecting malicious contents, for example, the Identity (''I'') of other users. As a result, the attacker can log into arbitrary user accounts and gain unauthorized access to their data.
forecast). To authenticate to '''S_bad''', SSO is used and the attacker specifically federates it with the same ''IdP'' used by '''S_target'''. After
[[File:XML_Signature_Wrapping.jpg|centre]]
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
<br> The authentication token is signed for a user Bob. Via ''XSW'' the attacker can inject a second ''Assertion'' containing another identity (e.g. admin). The verification logic will verify the Assertion pointed by the Ref, which is valid. The business logic (SSO Processor) will process the injected (malicious) ''Assertion''.
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
The SSO Verificator will verify the signature based on the contents of the original Assertion, which is selected by ID. However, if the SSO Processor’s program logic automatically processes the first Assertion found within the token, an attacker can bypass the integrity protection and enforce the processing of unverified data on the SaaS-CP.
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'''.


Let us review some different examples of ''Signature Wrapping attack'': <br>
[[File:Token_Recipient_Confusion.jpg|centre]] <br>
[[File:XSW_Example1.jpg|400px]]
SAML token addressed for service '''S_A''' will be sent to '''S_target'''.
[[File:XSW_Example2.jpg|300px]]
[[File:XSW_Example3.jpg|300px]]
<br> In '''Example 1''', the original message with '''ID="111"''' is included into the  signature child element. The verification logic finds this element and  accepts the signature as correct. The business logic, however, uses the Assertion directly bellow the Root.
<br> In '''Example 2''', the original message with '''ID="111"''' is included into the new '''"666"''' Response as the first child element (i.e., as a sibling of the signature element). The signature logic again finds the original message and accepts it as correct. The business logic uses the '''"666"''' Assertion that was included as the last child element of the new message.
<br> In '''Example 3''', the message contains two top-level elements of type Assertion. The signature logic verifies the signature of the original Assertion '''contained''' in the second Assertion and accepts it as correct. The business logic uses the first Assertion found in the message (i.e., the '''"666"''' Assertion).


=Mitigation / Countermeasures=
=Mitigation / Countermeasures=
The countermeasures depend on the [http://www.sso-attacks.org/XML_Signature_Wrapping#Attack_subtypes attack subtype] in use.
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.
The general approach would be to enhance the interface between the signature verification function and the business logic. In this approach, the signature verification returns some sort of position description of the signed data, next to a Boolean value.
The business logic may then decide if the data about to be processed has been signed or not.


=Practical Examples=
=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: Zoho, Clarizen, SAManage, Instructure, AppDynamics, Panopto, TimeOffManager, HappyFox, SpringCM, ScreenSteps Live and LiveHive.
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_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[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_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]
Line 51: Line 47:


=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). <br>
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>
[https://hgi.rub.de/media/nds/veroeffentlichungen/2011/10/22/AmazonSignatureWrapping.pdf Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, and Luigi Lo Iacono. All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces. In The ACM Cloud Computing Security Workshop (CCSW), October 2011.] <br>
[http://www.cvedetails.com/cve/CVE-2008-3891 CVE-2008-3891] <br>
[https://www.nds.rub.de/media/nds/veroeffentlichungen/2012/08/22/BreakingSAML_3.pdf Juraj Somorovsky, Andreas Mayer, Jörg Schwenk, Marco Kampmann, and Meiko Jensen. On breaking saml: Be whoever you want to be. In 21st USENIX Security Symposium, Bellevue, WA, August 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]

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