Replay Attack and XML Signature Wrapping: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=Introduction=
=Introduction=
Every [https://en.wikipedia.org/wiki/Single_sign-on SSO] protocol provides freshness parameters ''N'' to limit the reuse and lifetime of the authentication tokens. Taking into account that the reuse of tokens is optional, the validation of the attributes providing freshness is not considered as critical. On the other hand, the time restriction regarding the usage of authentication tokens is more critical and should be evaluated. Otherwise, tokens issued once might be valid for an extended time period or even an infinite amount of time.
The idea of ''XML Signature Wrapping (XSW)'' is to exploit the separation between SSO Verificator and SSO Processor. In case both logics
have different "views" of the same document, XSW can be applicable.
The goal is to force the SSO Verificator to use different elements than the SSO Processor.  


=Attack subtypes=
=Attack subtypes=
There are no attack subtypes for this attack.
There are several options to perform Signature Wrapping depending on the implementation of the verification logic:
*[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. More specifically, the token in question is required to be valid for the ''Software-as-a-Service Cloud Provider (SaaS-CP)'' at any time in the past. This can be achieved if the attacker had legitimate access (for a limited period of time) to the ''SaaS-CP'' via ''SSO'' and used this access to generate and store a token for himself. Alternatively, searching for published tokens in forums or in technical documentations could also provide valid, though most possibly outdated, tokens.
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.


=Target=
=Target=
[[File:Target_Verificator.jpg|centre|600px]]
[[File:Target_Verificator_and_Processor1.jpg|centre|600px]]
<br> The attacked Single Sign-On component is marked in red colour.
<br> The attacked Single Sign-On components are 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=
=Description=
The attacker sends an expired authentication token to the target ''SaaS-CP''. In case, that the unlimited reuse of authentication tokens is applicable and the token is successfully verified, the attack is classified as successful.
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.
The attack’s impact is average since the attacker has limited attack surface – he can only spend authentication tokens he possesses. However, the potential impact drastically rises in case the attacker gains hold of an authentication token granting him extended access rights (e.g., as an administrator of the system).
[[File:XML_Signature_Wrapping.jpg|centre]]
<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''.
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.


[[File:Replay_Attack.jpg]]
Let us review some different examples of ''XML Signature Wrapping attack'': <br>
<br>
[[File:XSW_Example1.jpg|400px]]
SAML token with expired timestamps is sent to the ''SaaS-CP''.
[[File:XSW_Example2.jpg|300px]]
 
[[File:XSW_Example3.jpg|300px]]
As can be seen in the example bellow, a SAML Response can contain several timestamps:
<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.
*'''Response:IssueInstant'''
<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.
*'''Assertion:IssueInstant'''  
<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).
*'''SubjectConfirmationData:NotOnOrAfter'''
*'''Conditions:NotBefore'''
*'''Conditions:NotOnOrAfter'''
*'''AuthnStatement:AuthnInstant'''
 
Thus, the timestamp validation logic is not simple. The implementor needs to pay close attention to the '''NotOnOrAfter''' attributes and also make sure, that the SAML Response matches the correct previous Request ('''SubjectConfirmationData:InResponseTo''').
 
<source lang=xml>
<samlp:Response
    ...
    IssueInstant="2015-12-05T09:22:05">
    ...
    <saml:Assertion
      ID="111"
      ...
      IssueInstant="2015-12-05T09:22:05">
      ...
      <ds:Signature>...</ds:Signature>
      <saml:Subject>
        <saml:NameID
          ...>
          Bob
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
            InResponseTo="request_1"
            Recipient="https://sp.example.com/SAML2/SSO/POST"
            NotOnOrAfter="2015-12-05T09:27:05"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2015-12-05T09:17:05"
        NotOnOrAfter="2015-12-05T09:27:05">
        ...
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2015-12-05T09:22:00"
        SessionIndex="session_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
        </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
</source>


=Mitigation / Countermeasures=
=Mitigation / Countermeasures=
This component should validate attributes providing the corresponding restrictions, i.e., the freshness parameter ''N''. In the SAML context relevant to this study, this parameter is represented by '''NotOnOrAfter''' and '''NotBefore'''. Failing to
The countermeasures depend on the [http://www.sso-attacks.org/XML_Signature_Wrapping#Attack_subtypes attack subtype] in use.
properly verify these parameters will enable this attack type. Another possibility to enable this attack type would be via additional freshness attributes, which are not part of the digital signature ''s''.
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: Clarizen, Instructure, AppDynamics, TimeOffManager, LiveHive and CA Service Management.
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.
 


[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
Line 83: Line 47:
[[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]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_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>
[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>
[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.]

Revision as of 19:18, 26 January 2016

Introduction

The idea of XML Signature Wrapping (XSW) is to exploit the separation between SSO Verificator and SSO Processor. In case both logics have different "views" of the same document, XSW can be applicable. The goal is to force the SSO Verificator to use different elements than the SSO Processor.

Attack subtypes

There are several options to perform Signature Wrapping depending on the implementation of the verification logic:

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.

Target

File:Target Verificator and Processor1.jpg


The attacked Single Sign-On components are 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

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.


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

Let us review some different examples of XML Signature Wrapping attack:

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

The countermeasures depend on the attack subtype in use. 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

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.

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