Herbalist Remedies

Room Description

https://dashboard.webverselabs-pro.com/challenges/herbalist

Scenario

Herbalist Remedies has been quietly selling single-origin tinctures online for a decade. The login form was written long before anyone on the team had heard the phrase "NoSQL injection." The admin account still uses a password nobody remembers — not that it matters.

Objective

Herbalist Remedies — an herbal-blend catalog — trusts its login form to compare MongoDB query objects. Slip an operator in and see who else is home.

Initial Analysis

Alrighty, so we have a challenge labeled with NoSQLi, let's get the reading materials out.

https://portswigger.net/web-security/nosql-injection

The homepage doesn't have anything fancy within it, it's just a list of articles that leads no where, we can get to the same endpoints through the dashboard as we can analyzing the page source.

Catalog brings you to the homepage, account takes you to a login page, since we aren't logged in yet, and sign in takes you to the login page as well.

Finding the bug

We can pretty much assume that the only place we really have to work with is the /login page, we could fuzz for directories, but a NoSQLi challenge means we should set our sights here for now.

Let's try to see what kind of error message a failed login gives, since this challenge might be that only one of the fields is vulnerable and we would need to enumerate for a user maybe?

Seems like a standard unified error message, so straight to bypassing the login we go!

Exploitation

Just to make sure we're up to par with our reading, the part we need is:

NoSQL operator injection

NoSQL databases often use query operators, which provide ways to specify conditions that data must meet to be included in the query result. Examples of MongoDB query operators include:$where - Matches documents that satisfy a JavaScript expression.$ne - Matches all values that are not equal to a specified value.$in - Matches all of the values specified in an array.$regex - Selects documents where values match a specified regular expression.

You may be able to inject query operators to manipulate NoSQL queries. To do this, systematically submit different operators into a range of user inputs, then review the responses for error messages or other changes.Submitting query operators

In JSON messages, you can insert query operators as nested objects. For example, {"username":"wiener"} becomes {"username":{"$ne":"invalid"}}.

Okay, so we have our login request sent to Repeater in Burp and change the "email" field to our payload.

{"$ne":"invalid"}

Interesting, maybe that's not the vulnerable field?

This also doesn't work, but there's a reason for it, the injection is literally a NOT EQUAL operator, and if a user called "test" or "admin" doesn't exist, then just adding the NOT EQUAL operator to our login request won't make the query statement true, so this means the next step for us would be to make both fields follow the logic of NOT EQUAL to test, and then the query will end up being true.

If we open the request in our browser to see the redirected output visually we have:

The view master record redirect is just a redirect to /admin/flag that holds the flag!