NeoVault

We are given a website like this:

Enumeration

A quick look at the source code of the website tells us that this is built with Next.js. Therefore, we can find available routes in the JavaScript files:

As can be seen, there are two API versions: v1 and v2. We must check if the endpoints from v1 are accessible. If so, they might have some vulnerabilities that were patched on v2:

$ curl -X GET 94.237.49.23:42577/api/v1/auth/me
{"message":"API v1 is deprecated, please use the new one instead"}
$ curl -X POST 94.237.49.23:42577/api/v1/auth/login
{"message":"API v1 is deprecated, please use the new one instead"}
$ curl -X POST 94.237.49.23:42577/api/v1/transactions/download-transactions
{"message":"Unauthorized"}
$ curl -X POST 94.237.49.23:42577/api/v1/transactions
{"message":"Unauthorized"}

Some of the endpoints are not accessible, but the ones for /api/v1/transactions look accessible, although we need to be logged in. So, let’s create an account and log in:

Surprisingly, we have received $100 bonus credit!

Let’s download the PDF file with the details:

With this, we know the name of the other account: neo_system.

Solution

Let’s inspect the web request that generated the PDF file:

We see that it comes from /api/v2/transactions/download-transactions. What if we change it to use API v1?

We need to provide an _id. For those not familiar, this _id is very likely to come from a MongoDB database, which is used as an object identifier, and should not be returned to the user, as it clearly identifies the database used by the server.

If we refresh the page and go again to “Transactions”, we will see a request that takes the information of the transaction, and we can see the _id of the user neo_system:

So, let’s use that to download the transactions from this user using this _id:

The request was successful, so we can say that the server’s API v1 is vulnerable to Insecure Direct Object Reference (IDOR), since we can download any PDF file with sensitive information as long as we know the _id of an existing user.

Now, we can save the response as a PDF file and have a look at it:

There seems to be another user called user_with_flag. As it names suggests, this username has the flag. So, let’s try to get a PDF as this user.

This can be quite difficult since we don’t know the _id of this user. However, we can guess that the server has another vulnerability related to MongoDB, namely it might be vulnerable to NoSQL injection. A typical payload to exploit NoSQLi vulnerabilities is to use a filter $ne, so that the results provide by MongoDB do not match some pattern. For instance, let’s use {"$ne": "x"}:

Well, the server requires a valid _id format, so let’s use the one we had before:

Flag

After saving the response a sa PDF file, we find the flag:

HTB{n0t_s0_3asy_1d0r}