Research, demonstrations, and popcorn


After doing some research into MongoDB for the company I currently work for, I started looking around at some servers online.  What I found was amazing.  Database servers almost never need to be exposed on the perimeter of a network, but there are thousands upon thousands out there exposed.  I have seen excuses ranging from “We have our servers hosted with a third-party vendor” to “we didn’t know we could secure it better.”

I initially did a search on Shodan for MongoDB instances where the authentication was disabled and the server lived inside the United States.  I found 14,972.  As of the time I pulled my first list on January 2, 2017, almost none of the servers had been touched.  Within ten days, almost every single one of them had been compromised by one of eight groups trying to hold the data ransom.  In most cases the data was not actually exfilltrated and no recovery is possible, even if the owner pays the ransom.

I started talking to Victor Gevers and Niall Merrigan on Twitter.  They had started researching and cataloging the ransom demands.  They are maintaining an Excel file online with a list of email addresses and bitcoin wallets associated with each of the people trying to hold the data ransom.  If you would like to view that document, it is linked from both of their Twitter accounts.

I wrote a small application to crawl through the unsecured servers and determine if they are still unsecured, online, and if they have been compromised.  Almost all of them have.

In fact, many of the servers I found to be compromised more than once.  The attackers are using scripts to automate the attacks.  They are not checking to see if the server has already been compromised, so they are just wiping out data and leaving their own ransom demand behind.  On many servers you can see multiple ransom demands from different groups.

I was just supplied a 2GB file with over 60,000 MongoDB hosts in it that may be compromised or at least vulnerable.  I have yet to run a scan on all of them yet as I am continuing research on other platforms than MongoDB.  I will post an update once I get some more results together.

So that brings me to the topic of securing your data…

Rule 1:  Do not expect a database application to secure itself.

Database applications such as MongoDB, Riak, and Microsoft SQL Server are designed to be useful database providing solutions.  They have a variety of security mechanisms built in that you can utilize.  Most have security configurations that can be pretty tough to break through.  The trick is, you have to actually utilize them.

Many of them (especially MongoDB) do not come secured out of the box.  They expect you to research a technology before using it and then configure the security to your specific needs.  I would like to see a more secure default configuration out of the box, but you can’t expect it to hold your hand.

Rule 2:  Don’t expose it publicly.

If you are using a third-party database server hosting provider and your provider does not allow you to provision your server with IPSEC or VPN, you probably want a new provider.  There is NEVER a good reason to expose a database server outside of your network unless you want to share every piece of data on that server, with the entire planet.

This is not a foolproof way to secure your data, but it will go a lot further than just leaving it hanging out there for anyone to steal.  Having the server routing inside your network and protected by your firewalls and the firewalls of the hosting provider is obviously much better for you and your data.

Rule 3:  Don’t use a technology you don’t understand.

If you are using a new database technology because a new project requires it or just because it is the latest and greatest thing out there, do not implement it until you know how to use it.  Ignorance is one of the biggest problems for security.  If you don’t know what the security features are or how to properly secure them, how could you possibly trust your data with it?

Again, picking on MongoDB, the default configurations are not setup to be secure.  It is setup so that you can download it, install it and connect to it… nothing else needed.  That is great for ease of use, but that is a nail in the coffin for security.  Know what you need to do to secure your data before you even setup the software the first time.

Rule 4:  Do not leave your administrative interface open to the world.

Many database technologies come with administrative interfaces that are shiny and web based.  I suspect that over 90% of them will have web interfaces by the end of 2018 (Microsoft SQL Server , et. all included).  Sure these interfaces are slick and shiny and make it so you can have any tool off the street manage some of the basic features… but do it from INSIDE your network.


This screen capture should never have been possible to take.  The administrative console for many Riak servers are just hanging out there exposed to the world with NO authentication on them.  These interfaces allow you to do things like wipe data, add and remove cluster nodes, and all sorts of fun things.  This should be protected.



Kalypto • January 15, 2017

Previous Post

Next Post