XSLT Attack and Replay Attack: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=Introduction=
=Introduction=
[https://en.wikipedia.org/wiki/XSLT ''Extensible Stylesheet Language Transformation (XSLT)''] is a language for transforming XML documents into other documents, for example, XML, HTML, JSON or even PDF. The XML Signature standard allows the usage of ''XSLT'' by definition, and thus, ''XSLT'' can be used in [http://www.sso-attacks.org/index.php?title=SAML SAML]. ''XSLT'' is a Turing complete language. By this means, it is possible to use XSLT, for example, to read/write files on the local filesystem and send them over the Internet. Furthermore, the ''XSLT'' transformation will be executed before the digital signature is verified. Thus, an attacker can send a ''SAML'' token including a digital signature containing the ''XSLT Attack (XSLTA)'' vector, but it is not required that the signature is valid. XSLTA allows accessing files within the context of the used web server.
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.


=Attack subtypes=
=Attack subtypes=
Line 6: Line 6:


=Prerequisites=
=Prerequisites=
In order to start XSLT, the attacker has to create a valid XML message containing a [https://en.wikipedia.org/wiki/Document_type_definition DTD]. Note, that the message has to be a SAML token. However, this token does not have to be signed with a valid key nor does the signature needs to be valid.
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.


=Target=
=Target=
Line 13: Line 13:


=Description=
=Description=
[[File:XSLT.jpg|centre|650px]] <br>
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 prepares a SAML token ''t'' and creates an XML Signature for it. Note, that it is not important to have a correctly computed signature value – the ''XSLTA'' only requires a well-formed XML document. The attacker adds a '''Transform''' element to the XML Signature and places the '''XSLT Payload''' in it as shown in Figure. <br>
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:XSLT1.jpg|centre]]


The attacker reads an arbitrary file using ''XSLT'' (in this example by using the ''unparsed-text()'' function). Afterwards, he forwards the contents of the file to his own server via a ''GET'' parameter.
[[File:Replay_Attack.jpg]]
<br>
SAML token with expired timestamps is sent to the ''SaaS-CP''.
 
As can be seen in the example bellow, a SAML Response can contain several timestamps:
*'''Response:IssueInstant'''
*'''Assertion:IssueInstant'''
*'''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=
The [https://en.wikipedia.org/wiki/Single_sign-on SSO] Verificator should mitigate the usage of ''XSLT'' within the token.
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
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''.


=Practical Examples=
=Practical Examples=
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Instructure.
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.


[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
[[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_Access_Control]]
[[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]]

Latest revision as of 19:16, 26 January 2016

Introduction

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

Attack subtypes

There are no attack subtypes for this attack.

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.

Target


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

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


SAML token with expired timestamps is sent to the SaaS-CP.

As can be seen in the example bellow, a SAML Response can contain several timestamps:

  • Response:IssueInstant
  • Assertion:IssueInstant
  • 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).

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

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

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.

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