The MongoDB hack and the importance of secure defaults

If you have a MongoDB installation, now would be the time to verify that it is secure. Since just before Christmas, over 28,000 public MongoDB installs have been hacked. The attackers are holding the hacked data ransom, demanding companies pay using Bitcoins to get their data back. From the looks of it, at least 20 companies have given in and paid the ransom so far. This post explains the hack, how to protect yourself, and what we can learn from it.

Understanding the hack

The hack itself is alarmingly simple. In versions >= 2.6.0, MongoDB includes a default configuration file that binds MongoDB to 127.0.0.1 by default. As a result, the database will only listen to local connections.

Before version 2.6.0, that wasn’t true. By default, MongoDB was left open to remote connections. Authentication is also not required by default, which means that out of the box installs of MongoDB before version 2.6.0 happily accept unauthenticated remote connections.

Users could still restrict access to local connections if they took the time to configure the install but that meant manually adding a line to their mongodb.conf file. Since that wasn’t the default configuration, many existing installs never included this critical step.

Making matters worse is that it’s easy to identify potential MongoDB attack candidates. MongoDB’s default port is 27017. Using a search engine such as ZoomEye, you can query for MongoDB installs, see what port they’re available over, and find around 100,000 vulnerable candidates.

The vulnerability itself is hardly new. The issue was first raised back in 2012 and released somewhere around 2015. Also, in early 2015, John Matherly made some noise when he reported finding around 30,000 insecure installs of MongoDB. In other words, this is something that everyone could have known about for a while.

The trouble with insecure defaults

The lack of insecure defaults is no minor issue. Study after study after study has shown that most people stick to the defaults a system presents to them. Defaults matter.

Now, some folks might argue that some of these insecure defaults are an attempt to balance usability and security, and that they are based on reasonable assumptions. If you can safely assume a database will be installed behind a firewall in the vast majority of cases, for example, then you may decide that not binding a database to local connections would be a reasonable default.

But assumptions like that are dangerous because when not if someone does something that breaks that assumption, they’re now vulnerable to attacks—and they may not even know it. Understanding of the potential security risks presented by these defaults is not exactly mainstream knowledge. Unless a company has security experts in place reviewing each decision (a good idea, but not a given), these insecure defaults can—an often do—remain overlooked.

Tracking insecure defaults

The trouble with insecure defaults gets worse.

Let’s say you’re a responsible organization and use a tool, like Snyk, to scan your tools and dependencies for vulnerabilities. Those tools won’t report this issue because insecure defaults are typically not considered vulnerabilities. This is because the issue itself here isn’t a bug or vulnerability in the code itself—it’s a configuration issue.

It makes sense, to an extent, but it does raise the question: should there be an official identifier and database for insecure defaults?

On the one hand, a service reporting insecure defaults would undoubtedly produce some noise. There are a lot of insecure defaults and some organizations will have already addressed them. These organizations would need to determine if the issue still applies to them, which isn’t always a simple task. If it doesn’t, they could safely ignore the issue and move on.

But reporting insecure defaults could be invaluable for those users who haven’t already identified these concerns. For them, it may alert them to security risks that would otherwise remain unnoticed and untouched—potentially (as in the case of the MongoDB issue) for years.

Flagging known insecure defaults in an open-source database (the same way we flag known vulnerabilities) would not have stopped this attack, but it could have prevented at least some of the databases from being affected.

So what happens next?

First of all, go secure your MongoDB installation. We’ll wait.

Now that you’re back, what this hack demonstrates is the massive importance of secure defaults. Security is too important to leave to chance. Just as the industry has been shifting to accept that sites should be served over HTTPS by default, package authors should be doing their best to ensure that their packages are secure by default. An insecure default setting can result in just as much damage as a known vulnerability. While it’s understandable that developers of these tools want to default to an install with the least amount of friction, the danger is that if that default is also insecure, we end up with situations like the one people are dealing with now for MongoDB.

The other question these attacks pose is whether it’s time to start tracking insecure defaults in an open-source database. At Snyk, we repeatedly discuss whether we should mark such flaws as vulnerabilities or not, and we will probably continue that conversation for a long while. If you have a strong opinion either way, do let us know—either by email or on Twitter. In the meantime, if you want to find out if your dependencies hold any security surprises, test your repos quickly using Snyk.