LFI Through XXE Injection

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!

In this article we’ll be taking a look into some more input vulnerabilities. Specifically, XML External Entity (XXE) Injection.

As web application security professionals and Bug Bounty Hunters, when testing for XXE vulnerabilities, ideally what we’re hoping for is the ability to first, define custom XML entities; however, ultimately what we’ll want to do is be able to read sensitive files on the web server.

Essentially though, LFI through XXE Injection is the same as with the other LFI vulnerabilities we’ve previously covered, but pertaining to XML files only.

Now, within the XXE Injection vulnerability-types, there’s a few sub-vulnerabilities. Together they’re:

Local File Disclosure

Advanced File Disclosure

Blind Data Exfiltration

We’ll be looking at the first one, Local File Disclosure.

He woke up
kind of feeling
like
he’d been
through Hell
and back

But that quickly
went away once
he got into web attacks.

Our first requirement when hunting a LFI vulnerability within the context of XML External Entities is to find a web page that accepts XML as user input.

To do that, once we’ve found a web page to test, say like the Contact Form that we’re using in our example, we’d need to intercept and examine our page in a proxy like Zap or Burp.

Looking at the highlighted portion of our screenshot below, we see that XML format is being sent to the web server in our request.

Also notice in our Response how the email address that we submitted into the form is being displayed/reflected back to us. This will be the element that we’ll want to target in our testing.

It’s through scribing
in his journal
that
he’d live
to tell the facts,

But this one’s
for the scratch

So he feels
like his head
is cracked.

Now our objective is to define an entity and use it as a variable in the email element.

What we’re trying to do in this step is see if the output is now reflecting the value that we defined.

Let’s have a look at the following screenshot.

The highlighted portions shows that we were able to define an entity in the email element- &company;.

It also shows our value is being reflected in the Response- Grey Hat Developer.

“Go in
and gain their
trust,
make ’em’ think that
that you won’t crack,”

Before
the crew
went black

He’s job
was to
dispel the hack.

Next we’ll proceed by attempting to define “external” XML entities. If we are able to do so, we may also be able to read sensitive files on the web server.

The example that we’ll be using is from HTB Bug Bounty Job Role, Web Attacks: XXE Injection.

Our task is to read the content of the ‘connection.php’ file and submit the value of the ‘api_key’ as the answer.

Can he
dupe it?

Hit the Dark Web
to get a Root Kit,
Searching for a shell
so he can
try and execute it.

Now he’s
stirring at a blinking
cursor,
looking stupid,

The tool
ain’t gonna help him
cause he don’t
know how to use it.

Exactly
like the data
cause he don’t know
what to do with it,

It’s not gone matter,
But see,
That’s where we confuse it.

Notice the highlighted portion of our Request looks a little different. Here we’ve added the SYSTEM keyword. Following the keyword, we’ve supplied a file path.

It’s worth pointing out that when we supplied the file path, we made use of a PHP wrapper and specified the convert.base64-encode encoder for a filter. Normally, our reference path would look like this – file:// as opposed to this – php://filter/, which is our filter.

What we see in our Response is our value which has been base64 encoded. To decode the value, we only needed to highlight it and Burp automatically decoded it inside of Inspector.

(The same can be accomplished with any base64 encoder. The following screenshot shows this being done in Burp Decoder.)

Imagine that
a web app
accepts X-M-L input

But doesn’t
place restrictions
on the values
that we can put.

Or validate the input,
Nor handle the exceptions….

Most likely
what we’re looking at’s
an
XXE Injection!

I realize this didn’t go too in depth with exploiting XXE’s but I wanted to keep this short and sweet. There’s still the other two sub-vulnerabilities that we’ll look at in subsequent posts.

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!