« SpiderLabs Radio March 15, 2013 w/ Space Rogue | Main | Baiting Attack Exercise – The Old School Way Still Works »

21 March 2013

Comments

We put together a simple checklist to improve security of your mongodb database - http://blog.mongodirector.com/10-tips-to-improve-your-mongodb-security/

I believe your word of caution is worth hearing: it's inviting to leave the default configuration and all too easy to find daemon's that are running in default configuration.

But to Mark's point, I recognized the other valuable recommendations as having come from the officials docs.

I also think it's far-fetched that someone would jump on the NoSQL bandwagon because it implies "NoSQLi," and don't see how items 1-6, exclamation points and caps and all, show that MongoDB is not less vulnerable to injection.

Mark,

The whole point of the blog was to inform people that default instances of Mongodb are being installed in live environments, and to provide a helpful script to find these instances, given that the default configuration has no authentication. Note the word 'default' is mentioned throughout.

So, if the 'default' configuration has no authentication enabled, my inference is you are trusting the people downloading and installing it to read your security best-practice and configure it securely. Again, my point of the blog is, this isn't happening in certain environments where I have tested. So, again, my conclusion is what I stated, that you are leaving the onus of the security to the people using it. Where is the problem with this fact?

Where in my blog did I say the developers of the product couldn't care less about security? The reason why I added the section for 'best-practice' was to inform people that there is a way of securing the default configuration, which your site quite rightly goes into detail. I apologize for not providing a link, but I think people reading this would have the intelligence to find it, given they are interested in the product, it is quite easy to find.

Again, I think you are missing the point that people are installing it using default configurations in live environments. I am not and did not attempt to review or research your road-map or future developments of the product. All I can comment on is the product I downloaded, and the experience of what i see in customer's environment and report on it.

I dont deem weak default installations of products as vulnerability information disclosure,and therefore there is no requirement to contact the developers in these cases. This is why 10gen were not contacted before this post.

If your 'honest' feeling is that not much work has been done on this research, of course you are entitled to your opinion. However I take a different approach that the people reading this will now be informed (if they didnt already know) of the security weakness that default installations and configurations of mongodb can be easily hacked without taking the appropriate measures to harden it using your own best-practice guidelines. And again providing a script to find these helps readers find these and address the issue.

Of course, I'd be glad to contact you directly if I should find information disclosure vulnerabilities in your product in the future. My blog was not one of these cases, given I was discussing default installations.

The fact that I see more instances of your product in the field show that it is indeed moving up the ranks and becoming more popular. The more popular it is the more chance there is of people installing it using default configurations.

Hopefully this post will help improve the security of their environments and the data.

Thanks for your feedback.

Hi David,

Thanks for your prompt reply.

I've worked in the security industry for quite some time, sadly done far too many courses/certs, and regularly had pen testers in my infrastructure so I'm quite familiar with how pen testing works and its goals etc.

>> Thanks for your comments and yes I did read your documentation.

Out of curiosity, how come there was no reference to it in the blog post when there's a picture of "developers of MongoDB" couldn't care less about security?

Additionally, is there a reason why there is no reference to the MongoDB documentation at the point when the details of best practices in securing MongoDB are provided in the blog post? Some of those recommendations look like they've been picked directly from the documentation on docs.mongodb.org/manual/security.

>> The mongodb security best practices page states you can reduce risk by installing it in a "trusted environment".

I think the documentation is being over-simplified here. The documentation does indeed say that, however, it goes on to provide configurations across multiple platforms on how to do this. The documentation also states what options/configuration should be turned on or kept off.

I agree that some of the initial design decisions around authentication, for example, are far from ideal. However, the documentation is extensive (yes, not everyone reads documentation but imagine if we didn't have it). The team are improving the security with every release, however, it must be noted that frequently changes can be backward-breaking and may negatively affect a lot of current production implementations then a lot of forethought and planning has to be involved. A MongoDB system that's down is very secure but it's not much good :(

>> If the developers of mongodb continue to leave the onus of the security to the people using it,

I'm perplexed as to how it is possible to make this statement given the changes in the current version, the roadmap, the vulnerability notification process and the detailed documentation on how to secure MongoDB (and this is not just vanilla documentation picked off the web)? To be honest, there doesn't appear to have been much research done here.

10gen would be delighted if next time prior to a blog post on MongoDB , you are able engage with 10gen prior to better understand the product and so we can better understand your concerns and issues.

By the way, MongoDB wasn't released in 2007, it was 2009. Development began in 2007, released in 2009 and the first production-ready build was in March 2010.

Thanks again for publishing your research on MongoDB.

Mark

Hi Mark,

Thanks for your comments and yes I did read your documentation. After having spent many years compromising databases such as MSSQL, and Oracle as a result of weak default authentication credentials I found it odd that the latest generation of databases could be installed with the same or similar issues. One part of my job involves going into peoples networks and telling them what I could access without any credentials. The reason I decided to write about MongoDB is because Im seeing it more often where people are deploying it on their networks without any credentials, thereby making it an easy target. Unfortunately, it is human nature to take the easy option and just install the defaults. In this case, mongodb
authentication is disabled by default, thereby human nature comes into play.

The mongodb security best practices page states you can reduce risk by installing it in a "trusted environment". The issue here is, a typical scope for my job is to find vulnerabilities in a customer's internal network. The customer believes their internal network is a "trusted environment". Therefore this means just by connecting my laptop to their environment, with a default mongodb configuration I will be able to access their database whatever it is. From a risk perspective, that¹s a high risk, as I have access to the data without any skill required to retrieve it. And this is happening now in live environments, from my experience.

And yes, mongodb has ways of improving its security, but that old human nature kicks in. Default installs are out there in the field.

Thanks for informing me of the latest versions and your roadmap again. I'll certainly take the time to look at the new versions coming out.

Thanks,
Dave

Hi David,

Thanks for your post. It's a good sign when MongoDB is coming to the attention of security researchers like yourself - be it posts like this, Metasploit modules or NSE scripts.

Regarding your recommended security hardening best practices, they look very similar to the ones that I wrote at http://docs.mongodb.org/manual/security/. I'm not sure if you hard a chance to review the documentation but we'd be delighted to know if you believe there's anything we can do better?

I see that you tested against MongoDB 2.2.2. You will be pleased to know that MongoDB 2.4 has been released (as of last week) and you can see some of the security enhancements that we have implemented at http://docs.mongodb.org/manual/release-notes/2.4/ and in particular, with regard to security, at http://docs.mongodb.org/manual/release-notes/2.4/#security-improvements.

We plan on releasing MongoDB 2.6 in Q4 this year and there will be further security improvements as per our roadmap at https://jira.mongodb.org/browse/SERVER?selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel.

After reading this documentation, seeing our roadmap and in particular, the new features in 2.4, I hope that you no longer feel that the "developers of mongodb continue to leave the onus of the security to the people using it" :)

Our vulnerability notification documentation can be found at http://docs.mongodb.org/manual/administration/vulnerability-notification/ and I wanted to let you know that we take security seriously at 10gen, so please if you have any issues or questions, please do not hesitate to let us know.

Additionally, all our issues or fixes are publicly tracked at https://jira.mongodb.org/browse/.

Thanks

Mark

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment