In light of the recent incident of MacKeeper exposing 13 million accounts through a public, unauthenticated MongoDB instances I wanted to quickly revisit my earlier blog post on the subject.

At the moment, there are at least 35,000 publicly available, unauthenticated instances of MongoDB running on the Internet. This is an increase of >5,000 instances since the last article. They're hosted mostly on Amazon, Digital Ocean and Aliyun (cloud computing by Alibaba):

The most popular versions of MongoDB are:

1. 3.0.7: 3,010
2. 2.4.9: 2,624
3. 2.4.14: 2,535
4. 2.4.10: 1,879
5. 3.0.6: 1,256

By default, newer versions of MongoDB only listen on localhost. The fact that MongoDB 3.0 is well-represented means that a lot of people are changing the default configuration of MongoDB to something less secure and aren't enabling any firewall to protect their database. In the previous article, it looked like the misconfiguration problem might solve itself due to the new defaults that MongoDB started shipping with; that doesn't appear to be the case based on the new information. It could be that users are upgrading their instances but using their existing, insecure configuration files.

In terms of data volume, all of the exposed databases combined account for 684.8 TB of data. And the most popular database names are:

1. local: 33,947
2. admin: 23,970
3. db: 8,638
4. test: 6,761
5. config: 859
6. test1: 612
7. mydb: 549
8. DrugSupervise: 382
9. Video: 376
10. mean-dev: 252

The database names are mostly the same as before, with the exception of: DrugSupervise and mean-dev. Notably absent is hackedDB which was at #8 last time.

Finally, I can't stress enough that this problem is not unique to MongoDB: Redis, CouchDB, Cassandra and Riak are equally impacted by these sorts of misconfigurations.

I would like to take a moment to discuss databases. Most people use Shodan to find devices that have web servers, but for a few years now I've also been crawling the Internet for various database software. I usually mention this during my talks and I've tried to raise awareness of it over the years with mixed results. At least with MySQL, PostgreSQL and much of the relational database software the defaults are fairly secure: listen on the local interface only and provide some form of authorization by default. This isn't the case with some of the newer NoSQL products that started entering mainstream fairly recently. For the purpose of this article I will talk about one of the more popular NoSQL products called MongoDB, though much of what is being said also applies to other software (I'm looking at you Redis).

Note: This article isn't about the way MongoDB scales.

Firstly, in an effort to make it a bit easier to understand the results for MongoDB I've updated the way they're represented in the search results:

A quick search for MongoDB reveals that there are nearly 30,000 instances on the Internet that don't have any authorization enabled. This was actually a bit surprising since by default MongoDB listens on localhost and has done so for a while based on the oldest Github checkin for their mongodb.conf. This made my results very confusing: how could there be so many open MongoDB installations if the defaults were to listen on localhost?

Configuration History

So I started downloading older versions of MongoDB to figure out when they changed the configuration defaults. It turns out that MongoDB version 2.4.14 seems to be the last version that still listened to 0.0.0.0 by default, which looks like a maintenance release done on April 28, 2015. I'm a bit confused why a configuration file was checked-in to Github September 2013 that listened on localhost by default, but then they kept distributing versions that didn't include that change?! I dug around some more and eventually found the official issue in Jira that tracked this configuration issue:

https://jira.mongodb.org/browse/SERVER-4216

Roman Shtylman actually raised this problem back in February of 2012! It ended up taking a bit more than 2 years to change the settings. Based on the distribution of versions I'm seeing, my guess is that early versions of 2.6 might've also lacked binding to localhost:

The lack of secure defaults explained some of the 30,000 results but just looking at the data made something else obvious.

The Cloud

The vast majority of public MongoDB instances are operating in a cloud: Digital Ocean, Amazon, Linode and OVH round out the most popular destinations for hosting MongoDB without authorization enabled. I've actually observed this trend across the board: cloud instances tend to be more vulnerable than the traditional datacenter hosting. My guess is that cloud images don't get updated as often, which translates into people deploying old and insecure versions of software.

Problem Scope

There's a total of 595.2 TB of data exposed on the Internet via publicly accessible MongoDB instances that don't have any form of authentication. To determine the scale of the problem I downloaded the data using the Shodan command-line tool:

shodan download --limit -1 mongodb "product:MongoDB"

And then I ran a small Python script to aggregate the total size of all exposed databases. I also looked at which database names were most popular:

1. local: 27,108
2. admin: 22,286
3. db: 9,895
4. test: 6,818
5. config: 1,119
6. mydb: 498
7. Video: 409
8. hackedDB: 319
9. storage: 315
10. trash: 309

Faceting on the database name reveals widespread installations that might've been misconfigured or otherwise exposed. There are a lot of instances that have some sort of administrative database, so the app that uses MongoDB probably has authentication but the database itself doesn't... The name that really sticks out is hackedDB. It's unclear whether those instances have been compromised or whether it's a large deployment of MongoDB servers from a company that uses "hackedDB" as its database name. Or maybe it's a honeypot? The interesting thing to note when looking at the results is that 40% of the instances are running a very old version of MongoDB (1.8.1).

I could go on and on about these sorts of problems because they're everywhere and haven't been resolved for years. Hopefully, more people will start looking at services that are responsible for the actual data and not solely focus on the web interfaces.