Absolutely everything on this blog pertaining to the term “hacking” is meant for training and educational purposes only. WE DO NOT ENGAGE IN NOR PROMOTE ANY ILLEGAL HACKING ACTIVITY!

Continuing with our research into XXE Injections.

So far we’ve exploited our XXE vulnerabilities using some basic XXE Injection techniques to read the contents of files on servers. But as we know, basic exploits that reveal only basic “low-hanging fruit” vulns, although they are legit finds, aren’t going to help us much in keeping our lights on.

Granted, we’re not saying that there’s not any value at all….it’s just that low-hanging fruits don’t rank high on the stakeholders priorities list, let’s put it that way.

Vulnerabilities
are not always
straightforward to exploit,

And all the ones that are

they can be found
with Metasploit. 

Somewhere throughout our journeys though, either as penetration testers, web application security testers, or Bug Bounty Hunters we’re going to run into some not so basic scenarios.

For instance, there’s cases where the web app that we’re testing won’t reflect any values that we throw at it, or cases where we won’t be able to read the file format using any of the basic techniques we’ve covered up to this point.

In this post we’re going to take a look at some methods at our disposal in these scenarios. 

Suppose we’re given an objective to, let’s say, read a flag that’s located at ‘/flag.php’ on a server. (This task was taken from the XXE Injection section of the Web Attacks module in the HTB Bug Bounty Job Role Path). 

To accomplish this task we have two advanced exfiltration methods at our disposal:

1. Exfiltration with CDATA
2. Blind exfiltration

So some formats
won’t be readable
through basic X-X-E,

And if you think
your payload
is repeatable
Let’s see.

Let’s look at the first one, CDATA. I won’t get too in depth with how it’s used here; however, you can work with the examples hands on yourself to gain the skills with the sources cited above. 

In our previous XXE Injection attacks we saw how important it was that our PHP source files were encoded with PHP filters, so as not to break our XML whenever we tried referencing it. 

When it comes to testing apps that weren’t built with PHP, we’ll need to use other methods to extract data from the database. In these instances, we can put our content inside of a CDATA tag. 

What happens when we do is that any special characters that would normally be parsed out, will be allowed due to the fact that CDATA is telling the parser to treat those characters as allowed. 

Whenever Mr. XML parser stops CDATA at the gate asking about his special character friends, CDATA co signs that it’s cool to let his friends into the party. 

However, when this fails, it means that XML is preventing us from joining internal and external entities. 

In this case, our solution would be to use XML Parameter Entities. These are entities preceded by the % character. Using these types of entities allows them to be referenced from our own server by joining them. As shown in the screenshot above. 

Once we do that and host the file on our server, we can then send our request to exfiltrate the contents of the file we’re targeting.

Since the web app
may not show us
any values through reflection,

we cannot
see the output
like we did
in other sections. 

So, the task of the module required that we use either method from the section to read the flag at ‘/flag.php’.

This is the CDATA method.

Now we’ll take a look at the second method.

The Blind Exfiltration Method

The blind exfiltration attack only differs in the way that we receive our output from the web application.

In the previous method the web application gave us our output to a specific XML Entity. With blind, the web application will send us our output directly to our server in the form of a web request.

Here we’ll create one entity for the file and use a PHP filter we’ve learned about in the earlier modules to encode it.

We’ll also need an external parameter. For the value of the parameter, we’ll use our file. We’ll send this as a web request to the server.

No denying….
that we must hide
our variables
with filters,

En-code our files
like Jesus did
in parables
through scriptures. 

To pull this off, the first thing we’ll need to do is start our server. After we issue a Request to the web application, the application will send it’s Response back to our server. From there, all is left to do is decode the file to reveal it’s contents.

Another thing to point out is not to forget to add the <root>&content;</root> element to the body of the Request.

So, our final task in the modules required us to, using the Blind Exfiltration method, read the content of ‘/327a6c4304ad5938eaf0efb6cc3e53dc.php’ and get the flag.

If an app
displays an error
but don’t handle
the exception, 

Then we can circumvent
this flaw
and use it
as our weapon.

Send some
badly formed data,
if we produce
an error,

This may reveal
the web directory
and
cause some terror. 

So let’s host
a D-T-D file
on a server
that we own,

And try to
read the content
of a file
that can’t be cloned. 

Get this bounty,
then we will
still be dancing
while it’s over,

Cause this was
all made possible
through Ad-Vance File Disclosure.

Here’s an excellent time for us to do a recap- So far our posts researching XXE Inections have covered Local FIle Disclosure, Advanced File Disclosure, and Blind Data Exfiltration.

As usual, this was a Proof-Of-Concept of us working through the HTB Bug Bounty course. (Hence the reason our solutions are obscured; this is so not to ruin anyone’s learning experience should they happen to be following along with the course themselves.)

Again, thanks for reading and be sure to Subscribe and Share our vibes with anyone you know who may be interested in Bug Bounty Hunting and web application security.

Until next time…Hack On, Ladz & Gentz!