On Null Byte Poisoning and XPath Injection

Recently I released a tool called XMLmao, a configurable testbed for learning to exploit XPath injection flaws, developing new attack techniques for XPath injection flaws or simulating real-world XPath injection scenarios, similar to SQLol. Among other features, it has challenge scenarios which give you a set of pre-configured options and an objective to complete. As of recently, I've begun to write tutorials for each challenge which will be distributed with their respective testbeds.

Since creating XMLmao, I've already begun to discover interesting approaches to different XPath injection scenarios. This wasn't hard, it was a matter of applying existing attacks applicable to other web application flaws to XPath injection. One example is the application of the Poison Null Byte attack to XPath.

Here's the tutorial for challenge 5, which expects you to use a null byte to complete the challenge:

Challenge 5 - Pipe Dream

=====================

In this challenge, we must retrieve passwords for all the users in our database without using the pipe character. Our initial query looks like this:

/xmlfile/users/user[username='OUR_INPUT_HERE']/username

It has been said that it is not possible to comment out the end of XPath queries as is done with SQL injection attacks. While this is true, we do have an option for truncating an XPath query prematurely: The Poison Null Byte.

C-based languages use the null byte as a string terminator and will stop reading any string given to it when reaching a null byte. Since libxml is written in a C-based language, the XPath query given to it by our PHP script (which actually reads the whole string) will be truncated if a null byte is present. The URL-encoded version of a null byte is "%00".

As we control the portion of the query which comes before the field in the user object is selected, we can truncate the portion of the query which specifies that only the username is to be returned. We can do this by closing the condition and truncating the rest with a null byte. The final query will look like this to PHP:

/xmlfile/users/user[username='']%00/username

And libxml will read it as:

/xmlfile/users/user[username='']

Our only problem is that this only returns the password for any user with a blank username, which is unlikely to return any data. As such, we can use our condition nullifying trick from Challenge 0 in tandem with the null byte to pull all data for all users, which includes password data. The final query looks like this:

/xmlfile/users/user[username='' or '1'='1']%00']/username

Which is read by libxml as the following:

/xmlfile/users/user[username='' or '1'='1']

This returns us the entire set of user data, without using the pipe character. So, one correct answer to Challenge 5 is:

' or '1'='1']%00

To try out this attack and more, go get XMLmao.

Comments

[Dan Crowley]

Hi Adrián,

You're absolutely right. Browsers will take characters with special meaning like the null byte or the percent sign and encode them to prevent mucking up the processes working with the data. As we're entering encoded data, we need to do it in such a way that the browser won't encode it again. One way of doing this, as you mentioned, is to put the data directly in the URL.

If the data isn't being submitted as a GET parameter (i.e. in the URL) we can use an intercepting proxy such as Burp Suite to modify the request and include our null byte.

It's great to hear feedback about the tool, especially that people like yourself are enjoying it! More challenges are in the works for both SQLol and XMLmao, so stay tuned!

Cheers,
--
dc

[Adrián Bravo]

Hi,

I've downloaded XMLmao v0.3 and for this null byte trick to work, you have to change it directly in the URL, because if you put %00 into the text box, is being encoded as %2500 in the URL and this won't work.

The tool is great, create more challenges please!
Regards,
Adrián