What MongoDB security issues are still unresolved?

What are the MongoDB security risks have not yet been resolved? Is there anything companies can do to mitigate the threats they pose before patches are available?

Recently, there was a surge of attacks looking for misconfigured installations of MongoDB on the internet. The attackers were abusing the lack of authentication and remote accessibility to these MongoDB instances by deleting an original database and holding a copy of it for ransom.

These and other MongoDB security misconfigurations and vulnerabilities aren't completely related to patch management, and are more in the realm of configuration management. There are a few ways to improve MongoDB security and protect your database from attackers.

The major issue here lies with certain versions of MongoDB coming with loose default configurations. The responsibility in this case lies firmly with the administrators installing the database software and not managing it appropriately.

I personally feel all software should be locked down by default, and should have certain features enabled only when needed, but if an application doesn't do this by default, and it's documented, then the responsibility falls to the administrators. Since older versions of MongoDB have loose default configurations, database administrators should validate a few things to start.

The first step to improve MongoDB security is to determine if the server running your database needs to have any inbound connections. Many times, these databases are housed remotely and require access from remote administrators. The default port for a MongoDB is 27017 and, if it's not only bound to 127.0.0.1, and the firewalls aren't locked down, attackers can access the database remotely.

Be sure to validate that only the proper ports are open, limit who can access the system and remove all access from the internet if it's not needed. Also, look into possibly using a VPN to connect to this instance if it has to be open over the internet to reduce visibility.

Secondly, validate the users who authenticate and run the database. One of the previous issues was that the default configuration allowed unauthenticated users to access the database over the internet. It's highly recommended to have some type of role-based access control instituted to limit the exposure of parts of the database that shouldn't be accessed by particular users.

Also, the user account running the database shouldn't have complete admin rights to the rest of the system. Limiting the rights directly to the application hardens it against other vulnerabilities that might arise within the application, such as SQL injection.

The third step to take to improve MongoDB security is to validate that the data within the databases is encrypted both in transit and in storage. There is native encryption, called WiredTiger, that can be utilized in particular MongoDB versions that helps secure the data within the database. This wouldn't have helped with the theft problem that occurred in the ransomware attacks, but would have secured the stolen data from being used. If an organization needs to access the database remotely, it should be done over TLS to secure the communication in transit.

Lastly, there are best practices like logging and auditing, vulnerability scanning, configuration and patch management that would have picked up on these issues. Without proper governance over MongoDB instances, or any system really, there can be a slow decline into an insecure posture that leads toward organizations being breached.

Ask the expert:
Want to ask Matt Pascucci a question about security? Submit your question now via email. (All questions are anonymous.)