Introduction

Sometimes, the way to bypass API auth is easier than you think. That’s all thanks to modern software development and the exponential growth of web services and cloud-based applications.

Let me explain.

APIs (Application Programming Interfaces) serve as the backbone for the seamless interaction between different software applications, systems, and services. They enable the integration of functionalities and data exchange, playing a pivotal role in digital ecosystems, from web applications to mobile apps and cloud services.

The rise of NoSQL databases has been a significant development in this landscape.

Unlike traditional SQL databases that use a structured query language for defining and manipulating data, NoSQL databases are designed for specific data models and have flexible schemas for storing and retrieving data.

This flexibility makes them well-suited for handling large volumes of unstructured data, which is increasingly common in big data, real-time web applications, and the APIs driving these applications.

Popular NoSQL databases like MongoDB, CosmosDB, Cassandra, and Couchbase have become the backbone for many applications due to their scalability, performance, and ease of use.

However, this shift also brings new security challenges.

NoSQL databases handle queries and data differently, requiring a fresh approach to securing databases and the APIs that interact with them. The traditional security measures and tools designed for SQL databases are often not directly applicable to NoSQL environments, leading to potential vulnerabilities like NoSQL injection attacks.

In this article, we will explore how you can check to see if it’s possible to bypass API auth by injecting potentially malicious data into the login payload.

Here we go…

Understanding NoSQL Injection

NoSQL injection is a type of web application security vulnerability that allows an attacker to manipulate the queries that are passed to a NoSQL database.

Unlike traditional SQL injection, which manipulates the SQL query using harmful input data, NoSQL injection targets the database query itself. This is mainly due to the usage of API calls or object literals to query NoSQL databases instead of the standard SQL syntax.

Given their flexible schema, NoSQL databases are particularly vulnerable to these kinds of attacks, emphasizing the need for stringent data validation and effective security measures.

Where can NoSQL injection be abused?

Common scenarios where NoSQL injection can be exploited in APIs often involve areas where user-supplied input is improperly sanitized and is directly used in database queries.

For instance, authentication mechanisms can be prime targets if they rely on user-provided credentials to validate access. An attacker could exploit this by injecting a NoSQL query that manipulates the authentication logic, allowing them to bypass API authentication.

That’s what we will be looking at today.

Other vulnerable points include APIs that perform search operations, update user profiles, or any functionality that involves direct user input. All these scenarios underline the criticality of validating and sanitizing user inputs to ensure they do not contain malicious NoSQL queries.

It’s a regular theme around here. Taint all the things… because developers keep forgetting to sanitize their inputs.

Identifying Vulnerable APIs

Identifying APIs that use NoSQL databases often requires close scrutiny of the API’s behavior and responses.

One technique involves testing the API endpoint with different input types, including arrays and objects. NoSQL databases may respond uniquely to such inputs, providing a clue to their underlying technology.

Moreover, certain NoSQL databases like MongoDB use distinctive operators such as $ne or $regex, which can be used in payloads to identify their usage.

Specific error messages or unusual responses can also reveal the use of NoSQL databases. It’s not uncommon to see an error message that might leak data schema details or other sensitive information.

However, it is essential to approach this process cautiously, as probing live APIs can inadvertently disrupt their functionality or lead to unintentional security breaches.

Tools that can help

Several tools can aid in testing for NoSQL injection vulnerabilities:

1. NoSQLMap: Designed as a pentesting tool, NoSQLMap helps identify and exploit NoSQL database vulnerabilities. It supports a variety of NoSQL databases and provides automated features.
2. NoSQL Exploitation Framework: This framework, written in Python, enables penetration testers to exploit configuration and implementation flaws within NoSQL databases.
3. NoSQL Attack Suite: This is a collection of NoSQL exploitation scripts that are made to automate attacks against NoSQL databases. The first can bypass logins, and the second can dump the NoSQL database.
4. Nmap: Although primarily a network scanning tool, Nmap can detect NoSQL databases by using scripts such as ‘mongodb-databases‘ and ‘mongodb-info‘ in its scripting engine.
5. Burp Suite: Burp Suite includes a scanner feature that can identify NoSQL injection vulnerabilities. There are also extensions like the NoSQLi Scanner that can do a more thorough evaluation.

The reality though is that tools can only do so much. When looking to bypass API auth, you can follow a few manual processes to quickly test for NoSQL injection.

Bypassing Authentication with NoSQL Injection

When looking at bypassing authentication in an API, you should start by finding the endpoint responsible for accepting and validating credentials during a user’s login attempt.

This will typically include a username and password as part of the credentials but may include additional details. Our testing will only focus on the username and password fields.

Crafting NoSQL injection payloads involves the creation of malicious data aimed at exploiting vulnerabilities in a NoSQL database. To bypass API authentication, you need to construct a payload that tricks the system into granting unauthorized access.

Such a payload might target the authentication mechanism by injecting specific operators or logic that manipulate how the system interprets queries. For instance, in MongoDB, you might utilize the ‘$ne‘ operator, equivalent to ‘!=‘, to alter the logic of the authentication query. Instead of the system checking for an exact match of username and password, the manipulated query might check for a username that is not equal to an arbitrary value, effectively sidestepping the need for a correct password.

Remember, the primary aim is to negate or bypass the standard security checks, but the specific payload will largely depend on the type of NoSQL database and its specific weaknesses.

Basic API auth bypass technique

I always recommend that you start by capturing a proper login attempt in Burp. Look at the body and determine the field names that represent the username and password. Send that request to the Repeater tab.

Let’s assume for a moment that those fields are named user and pass, respectively.

A basic bypass for a Content-Type of application/x-www-form-urlencoded might look like this:

user[$ne]=fu&pass[$ne]=bar

If the login endpoint is accepting JSON, it might look something like this:

{"user": {"$ne": "fu"}, "pass": {"$ne": "bar" }}

Why does this work?

Well, think about how the NoSQL query is constructed.

Consider some vulnerable nodeJS API code that takes the credentials directly:

app.post('/login', function (req, res) {
  db.users.find(
    { username: req.body.user, password: req.body.pass },
    function (err, users) {
      // TODO: handle the login and return a JWT access token
    }
  )
})

But our malicious input modifies that behavior. It turns the expected string input into a query operator, ultimately changing the lookup to look something like:

db.users.find({username: {$ne "fu"}, password: {$ne "bar"}})

How that now reads, it’s telling NoSQL, “Find me a username that doesn’t equal ‘fu’ and whose password is not ‘bar’.“. This is the essence of how to bypass API auth.

This will probably return the first user in the collection… which is usually the super user, or at the very least, the first user who probably has admin privileges.

Of course, if you know the user account you want to log in as you can modify the query accordingly. For a user named Bob, it might look like this:

{"user": "bob", "pass": {"$ne": null }}

See what I did there? Not only did I explicitly define the username I wanted, but I also told NoSQL I wanted to log into Bob’s account as long as his password was not null… which is a pretty good bet.

Conclusion

A comprehensive understanding of NoSQL injection is pivotal for API security in this digital era. The ability to bypass API auth using NoSQL injection demonstrates the vulnerability that exists when inputs directly influence query construction.

Just because it’s using NoSQL doesn’t mean there is no injection. It just works differently than SQL injection.

Manipulating the login payload to change the expected string into a query operator exposes a risky loophole. It leads to an unintended behavior, potentially returning access to accounts that may have higher levels of privilege than expected, thereby compromising system integrity.

So give it a try the next time you are conducting an API pentest. Check to see if NoSQL may be in use, and then try to taint the login payload with an operator to modify the authentication behavior to act differently.

You might be surprised by what you find.

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post The No-Nonsense Guide to Bypassing API Auth Using NoSQL Injection appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/bypassing-api-auth-using-nosql-injection