Skip navigation

Why the MongoDB Ransomware Shouldn't Surprise Anyone

Recent reports have discovered MongoDB instances being targeted with ransomware. Current estimates at the time of this writing suggest that there have been over 28,000 unique cases of ransomware from multiple actors targeting hosts running MongoDB.

MongoDB, as well as many other NoSQL database solutions, have a track record of shipping with insecure default configuration settings including listening on all interfaces as well as providing read/write access without authentication. Insecure default settings as well as simple misconfigurations on the part of administrators expose the hosts to information theft.

This post aims to provide a bit of background on exposed MongoDB instances, as well as give some helpful tips and resources on securing a MongoDB deployment.

This Shouldn’t Be a Surprise

Exposed MongoDB instances have been discussed by researchers for years. Throughout 2015, researcher Chris Vickery discovered multiple accessible MongoDB instances, exposing hundreds of millions of records containing potentially sensitive information.

Shodan, a search engine for Internet-connected devices, has reported on exposed MongoDB databases multiple times, measuring over 680 TB of data exposed by open MongoDB instances.

Researchers at BinaryEdge did a similar study on the exposure of different storage solutions and found that hundreds of MongoDB instances had a database created with the name DELETED_BECAUSE_YOU_DIDNT_PASSWORD_PROTECT_YOUR_MONGODB, which is similar to the attacks we’re seeing now. A follow-up study showed that the number of open MongoDB instances only increased over time.

Even the case of ransomware targeting storage services isn’t new. Last year, we discovered that actors were targeting Redis with fake ransomware. In the case of the Redis attacks, attackers were simply deleting the data and asking for a ransom. This appears to be the same scenario as at least some of the MongoDB attacks, with victims paying the ransom and reporting that they did not receive a copy of their data..

Nearly every instance of compromised MongoDB databases could be prevented by employing standard security best practices.

How to Protect MongoDB

The team behind MongoDB responded to the ransomware attacks in a blog post that directs readers to the MongoDB security manual as well as a security checklist that can be used to make sure a deployment is using best practices.

At a high level, we recommend using these simple controls to help create a baseline of MongoDB security:

Limit Network Exposure

The easiest way to prevent attackers from compromising a MongoDB instance is to limit their ability to connect at the network layer. The MongoDB configuration file specifies a net.bindIp entry which can be used to force MongoDB to bind to localhost. It should be noted that, as of version 2.6, MongoDB ships in many distributions with this already set to localhost instead of binding to all interfaces.

If you need to allow access to a MongoDB instance from another host, we recommend using firewall rules to allow access from only authorized hosts.

Configure Role-Based Access Control

MongoDB supports role-based access control (RBAC) which allows for the creation of multiple users with different levels of access. We recommend configuring user accounts with the least privileges required as well as ensuring that strong passwords are used for authentication.

Perform Regular Backups

Any critical data should be regularly backed up and stored in case the original copy is somehow lost. MongoDB provides the mongodump and mongorestore utilities to easily backup and restore database contents.

Check out MongoDB’s security checklist for the full list of security recommendations.

Moving Forward

At the time of writing, Shodan estimates that there are over 47k MongoDB hosts exposed to the Internet, indicating that the number of hosts targeted by ransomware may continue to climb.

While these latest attacks may prompt MongoDB administrators to lock down their deployments, this likely won’t be the last time we see ransomware target data storage solutions.

Back in October, we performed research into the exposure of different NoSQL databases and key/value stores. During the research, we found a substantial number of hosts using different technologies such as Memcached, MongoDB, Redis, and Elasticsearch.

Exposed Key/Value and NoSQL Databases

Since these hosts store critical (and often sensitive) information, are accessible to anyone without authentication, and vulnerabilities (such as these for Memcached) continue to be released, it is likely that ransomware will continue to target these technologies until action is taken to secure them.

Using best security practices for these technologies significantly reduces the attack surface and helps protect your data from attackers.

For more information including a more complete list of information leaks resulting from open MongoDB instances, you can find the full slides from our talk here.

Jordan Wright

Research & Development Engineer

@jw_sec

Jordan Wright is an R&D Engineer at Duo Security as a part of the Duo Labs team. He has experience on both the offensive and defensive side of infosec. He enjoys contributing to open-source software and performing security research.