Uncle Rat’s (Almost) Full Guide To XXE

XXE is one of my favourite attack types because it’s usually hidden below a surface level concealment. We all know that almost nobody uses XML files anymore these days as JSON has taken over and even YAML. Yet the fact XXE appears in the OWASP top 10 of 2017 does say something about this vulnerability type.

Today we are going to look at all the possible attack vectors that we can think of, both from the perspective of a pentester and of a bug bounty hunter. Defending your application against XXE attacks is not simple either so i hope this will give anyone building a web application some ideas as to how to protect their application better.

Before we start talking about XXE, we need to talk about the blind aspect of XXE attacks. Whether you are a pentester, bug bounty hunter or ethical hacker in general, it’s always a good idea to look for blind XXE over normal XXE. This will ensure that you will not miss any entry points as sometimes we might be testing for XXE and think an endpoint is not vulnerable because we do not see any data being returned while in all actuallity the endpoint might be vulnerable to blind XXE.

Blind XXE means that you are performing a succesfull attack but that you are not seeing any output from the server. This means that in order to confirm whether or not our attack was successful, we need to make a request to an external server. I usually use the burp collaborator to test for this vulnerability and will also make sure to test for non blind vulnerabilities after that as well in case we do have a verbose defect but the egress filtering is enabled or something like that. Egress filtering means when a firewall filters outgoing traffic and does not allow certain outgoing requests like HTTP requests.

We’ve talked about this a little bit already but for XXE to occur, we need to have an XML processor at work in the background. An XML processor will take in any XML file and will by default allow for external entities to be included. These entities can be anything ranging from system commands like ls (maybe even a reverse shell?) to files like /etc/shadow.

The good thing is that if we do find an XXE attack, it doesn’t matter if we are a pentester or a bugbounty hunter. The severity of this issue will always be at least medium if you can find files on the system and probably even higher if you can execute commands. Just make sure you don’t forget to prove impact, you don’t want to lose all this work because you did not prove any impact.

Most people know what a conventional XML file looks like.

If we can import this XML file into our application to create a note we have an entry point for XXE attacks but this almost never happens!

You really don’t see much XML out there at all anymore. Most applications will use different types of data formats yet this vulnerability is number 4 in the top 10 OWASP list of 2017. Does this mean that XML files are becoming a hot topic again? No, ofcourse not! Good riddance to that old outdated technology!

There are other entry points for XML attacks that most hunters might not have heard about or they might not have given it a second look.

This is one of my favourite ones because almost every website will have some option to upload a picture and render that picture. This is what SVG is in essence and though it may seem more complicated than that, it is not. It is in fact just an image but described in an XML format. This means that if the server allows SVG files that we can always test for XXE.

This SVG file will try to open the file:///etc/hostname and display it to the user.

But we can also just test for blind XXE to start with. We can save these texts as ‘Anything.SVG’ and try to upload them anywhere that we can upload an image and that the image would render for example in profile pictures or banners.

Attacking a target sometimes means getting creative … very creative. It may not seem directly apearant but we can also test for XXE via PDF upload functionality. Again the target will need to render the PDF to test for XXE attacks because if you can simple upload a PDF file but it will never render then the server will also never try to render your XML attack string.

According to hacktricks if the following attack string is accepted we can also check if XML input is accepted.

We can then try if XML input is also accepted

And subsequently we can add our XXE attack string but ofcourse only if the XML input is accepted and processed.

Most web applications these days accept JSON as input and it seems like this covers most entry points for XXE pretty well since if we can’t work with XML files; it will be really hard to execute an attack that pivots on the XML format. Or will it? It may not be as foolproof as many people think it is.

https://book.hacktricks.xyz/pentesting-web/xxe-xee-xml-external-entity#content-type-from-json-to-xee

According to hacktricks we can simple change the content type header. This will take advantage of the fact that some servers have XML processors built into them by default and if the developer never disabled them, we can use those to yet insert XXE attack vectors. Let’s look at the example hacktricks gave us.

We can simply change the content type and test if this still works and if the content will be processed by the webserver.

This ofcourse means we also have to change the body to an XML format. To do this i use a JSON to XML converter.

https://www.freeformatter.com/json-to-xml-converter.html

Combining all this we get

We can also use the Burp Extension named “Content Type Converter“ though i like to at least explain how you can do it manually as well.

If the server also accepts this request we can try to enter our XXE attack vector.

In this example only the first node ‘Firstname’ is tested but ofcourse we need to test all the nodes because XXE can occur on every single node. This happens because the developer either has to secure every node seperately on some XML processors.

SOAP stands for Simple Object Access Protocol, it’s basically another protocol such as HTTP or FTP but SOAP uses an XML like structure to communicate. The keen eyed among you might have already guessed that SOAP is thus also possibly vulnerable to XXE attacks but we will again have to make sure we test every single node. In SOAP every single node will have to be secured by the developer so we can also test for other things in here like SQLi and XSS due to this fact.

This is the free version of the document on XXE, to get a full version including video coverage for just 2$ (Less than the price off a coffee), head over to https://gum.co/ZbQkN