Blind Data Extraction

MangoPost

In the following two sections, we will look at MangoPost. This website is vulnerable to blind NoSQL injection, which we will leverage to extract data.

The webpage is a simple package tracking application where you can enter a tracking number and get information about the shipment.

We can search for a known tracking number (32A766??) and intercept to request to see what is sent to the server and what sort of information we receive.

The request sends the trackingNum that we inputted and nothing else. The fact that a JSON object is sent and not URL-encoded data like in the previous two examples is worth noting down.

You may notice that the page does not refresh or redirect anywhere when the form is submitted. This is because of a JavaScript script in the page, which converts the form data into a JSON object, sends a POST request with XMLHttpRequest, and then updates the tr-info element in the page. We can view it by pressing CTRL-U or going to view-source:http://SERVER_IP:PORT/index.php

Knowing that trackingNum is the only piece of information we send when looking up packages, we can assume the query being run on the back end looks something like this:

db.tracking.find({
    trackingNum: <trackingNum from JSON>
});

The NoSQL injection here should already be clear. We can use techniques we already covered to return tracking information for some package.

For this section, however, we are interested in finding out what the trackingNum is. We can not find this out directly since trackingNum is not included in the information returned to us. What we can do, though, is send a series of "true/false" requests that the server will evaluate for us.

So, for example, we can ask the server if there is a trackingNum that matches $ne: 'x', and the server responds with package info.

Likewise, we can ask the server if there is a trackingNum that matches $eq: 'x', and as expected, the server will tell us there is no such package.

At this point, we know that we can ask the server if there is a trackingNum that matches some arbitrary query we provide, and it will essentially tell us yes or no. We call this an oracle. We can not get the information we want directly (trackingNum), but we can supply arbitrary queries using the server's responses to leak the information indirectly.

Leaking Franz's Tracking Number

Earlier in this section, we used the tracking number 32A766??. Let's look at how we could leak this number if we didn't know it.

For our first query, we can send {"trackingNum":{"$regex":"^.*"}}, and it will match all documents. The one returned to us is addressed to Franz Pflaumenbaum. There could be multiple packages in the collection, so to make sure we are leaking information from the same package we will be looking for Franz Pflaumenbaum in the server's response to make sure we are targeting the correct package.

For our next query, we will send {"trackingNum":{"$regex":"^0.*"}} to try and see if the trackingNum starts with a 0. This returns This tracking number does not exist, which means that there are no tracking numbers in the collection that start with 0, so we can count that out.

Next, we will repeat this with 1, 2 until we get to {"trackingNum":{"$regex":"^3.*"}}, which returns Franz's package info. Now we know that his tracking number starts with a 3.

Let's move on to the second digit. The request {"trackingNum":{"$regex":"^30.*"}} returns This tracking number does not exist, so we know the second digit is not a 0, but we can keep trying characters until we get to {"trackingNum":{"$regex":"^32.*"}} which does return Franz's package information meaning the next character in his trackingNum is a 2.

We can continue this process until the entire package number is dumped. Note that the package number does not only contain numbers but letters also. A dollar sign ($) is appended to the regular expression to mark the end of a string, so in this case, we can verify the entire trackingNum has been dumped.