In last couple of years, the MEAN stack (MongoDB, Express.js, Angular.js and Node.js) became the stack of choice for many web application developers. The main reason for this popularity is the fact that the stack supports both client and server side programs written in JavaScript, allowing easy development.
The core database used by the MEAN stack, MongoDB, is a NoSQL database program that uses JSON-like documents with dynamic schemas allowing huge flexibility.
Although NoSQL databases are not vulnerable to standard SQL injection attacks, they can be exploited with various injection vulnerabilities depending on creation of queries which can even include user-defined JavaScript functions.
This diary is actually based on a real penetration test I did on a MEAN based application that initially looked completely safe. So let">db.products.find( { qty: { $gt: 25 } } )
This is important for us as penetration testers since we can potentially influence how a query will be executed and we all know that as long as we can modify input parameters we can make the database do whatever we want it to do (or close enough).
Notice here that JSON, which is used to format queries, has different dangerous characters than those we know from SQL databases: here we care about characters / { } :
Easy development with MEAN
One of the best things of the MEAN stack is that it is very easy and simple to develop web applications. After setting some basic configuration, it is trivial to create a route to our own JavaScript function that will handle certain requests. Let">app.get(/documents/:id">a9577050-31cf-11e6-957b-43a5e81bf71e) and search for it in MongoDB.
Notice here that, although the URL looks static, it is not static at all the GUID here is a parameter that is later used in a function. A question for you: what will your web scanner of choice try to do with this query? Will it insert a ">db.collection(documents">var searchparam = JSON.parse({ \friendly:\ + param + }">db.collection(documents">id parameter taken from the HTTP body) into a JSON string.
Now, as you can probably presume, this is treated differently by MongoDB.
Exploitation time
In case above we can actually manipulate the query quite a bit. Let">$ curl http://vulnsite/documents/ -d id={ \\$ne\: null }">{ $regex: ^a">{ friendly: { $regex: ^a} }
And this will retrieve the first document whose GUID starts with the character a. Nice! We can now retrieve things character by character and do not have to brute force it any more. And just in case we have some kind of WAF (does your WAF understand">{ friendly: { $in: [ /^a/ ] } }
This will result in the same document.
As we can see, NoSQL databases and applications that use them can also be quite vulnerable to injection attacks, so we should never underestimate what an attacker can do that can manipulate input parameters: we should always properly filter and sanitize them.
MongoDB actually supports quite a bit of search operators that can be used in this example you can read more about them at https://docs.mongodb.com/manual/reference/operator/
As NoSQL databases are becoming more popular, I am sure that we will see new and innovative attacks against them. Interesting time is coming for sure!
--
Bojan
@bojanz
INFIGO IS
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
