When the fine folks at Portswigger updated Burp Suite last month to 1.6.07 (Nov 3),  I was really glad to see NoSQL injection in the list of new features.  

What's NoSQL you ask?  If your director is talking to you about "Big Data" or your Marketing is talking to you about "customer metrics", likely what they mean is an app with a back-end database that uses NoSQL instead of "real" SQL.  

I'm tripping over this requirement this month in the retail space.  I've got clients that want to track a retail customer's visit to the store (tracking their cellphone's using the store wireless access points), to see:

• if customers visit store sections where the sale items are?
• or, if customers visit area x, do they statistically visit area y next?
• or, having visited the above areas, how many customers actually purchase something?
• or, after seeing a purchase, how many "feature" sale purchases are net-new customers (or repeat customers)

In other words, using the wireless system to track customer movements, then correlating it back to purchase behaviour to determine how effective each feature sale might be.

So what database do folks use for applications like this?  Front-runners in the NoSQL race these days include MongoDB and CouchDB.  Both databases do cool things with large volumes of data.  However, while both are making huge strides in securing the database app, their current versions both still need quite a bit of TLC in the security space - and of course nobody deletes the old instances, so the original-original problems are still all there.

Luckily, both databases have good (and relatively honest!) security documentation, and both of them explicitly call this situation out.

MongoDB states this nicely at http://docs.mongodb.org/manual/administration/security-checklist/ :

"Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available."

CouchDB has a similar statement at http://guide.couchdb.org/draft/security.html "

"it should be obvious that putting a default installation into the wild is adventurous"

So, where do I see folks deploying these databases?  Why, in PUBLIC CLOUDs, that's where!  Because what better place to put a database that has all kinds of customer data than outside your IPS and other security controls?

And what happens after you stand up your almost-free database and the analysis on that dataset is done?  In most cases, the marketing folks who are using it simply abandon it, in a running state. What could possibly go wrong with that?  Especially if they didn't tell anyone in either the IT or Security group that this database even existed?

Given that we've got hundreds of new ways to collect data that we've never had access to before, it's pretty obvious that if "big data" infrastructures like these aren't part of our current plans, they likely should be.  All I ask is that folks do the risk assessments tha they would if this server was going up in their own datacenter.  Ask some questions like:

• What data will be on this server?
• Who is the formal custodian of that data?
• Is the data covered under a regulatory framework such as HIPAA or PCI?  Do we need to host it inside of a specific zone or vlan?
• What happens if this server is compromised?  Will we need to disclose to anyone?
• Who owns the operation of the server?
• Who is responsible for securing the server?
• Does the server have a pre-determined lifetime?  Should it be deleted after some point?
• Is the developer or marketing team that's looking at the dataset understand your regulatory requirements?  Do they understand that Credit Card numbers and Patient Data are likely bad candidates for an off-prem / casual treatment like this (hint - NO THEY DO NOT).

Smartmeter applications are another "big data" thing I've come across lately.  Laying this out end-to-end - collecting data from hundreds of thousands of embedded devices that may or may not be securable, over a public network to be stored in an insecurable database in a public cloud.  Oh, and the collected data impinges on at least 2 regulatory frameworks - PCI and NERC/FERC, possibly also privacy legislation depending on the country.  Ouch!

Back to the tools to assess these databases - Burp isn't your only option to scan NoSQL database servers - in fact, Burp is more concerned with the web front-end to NoSQL itself.  NoSQLMAP (http://www.nosqlmap.net/) is another tool that's seeing a lot of traction, and of course the standard "usual suspects" list of tools have NoSQL scripts, components and plugins - Nessus has a nice set of compliance checks for the database itself, NMAP has scripts for both couchdb, mongodbb and hadoop detection, as well as mining for database-specific information.  OWASP has a good page on NoSQL injection at https://www.owasp.org/index.php/Testing_for_NoSQL_injection, and also check out http://opensecurity.in/nosql-exploitation-framework/.

Shodan is also a nice place to look in an assessment during your recon phase (for instance, take a look at http://www.shodanhq.com/search?q=MongoDB+Server+Information )

Have you used a different tool to assess a NoSQL Database?  Or have you had - let's say an "interesting" conversation around securing data in such a database with your management or marketing group?  Please, add to the story in our comment form!

===============
Rob VandenBrink
Metafore