MongoDB has worked hard over the past few years to improve the security of its flagship MongoDB database server. It desperately needed to do this because MongoDB has been subjected to more high-profile attacks than any other database platform.
Early releases of MongoDB allowed—even encouraged—the installation of a database server with absolutely no authentication mechanism enabled. This meant that anybody who had access to the database port—normally 27017—would be able to connect to the database with unlimited authority.
MongoDB was a popular choice for developers during the transition to cloud-based servers such as those hosted by Amazon AWS. These default database systems were completely open to hackers.
From 2014 through 2017, cloud-based MongoDB databases were routinely attacked, and several high-profile data heists enabled. In 2017, a particularly widespread wave of ransomware attacks plagued MongoDB cloud databases leading in many cases to the total loss of data.
It’s true that the developers and DBAs who installed these databases are ultimately responsible for the absence of any configured security. However, MongoDB themselves contributed to the problem by making the database installation insecure by default. The 3.6 release of 2017 closed external access by default, ensuring that default installations were protected from external attack. MongoDB 3.6 also introduced IP whitelisting, which restricted network access to approved IP addresses.
Each subsequent release improved the security of the MongoDB server. In version 4.0 the Atlas cloud server added LDAP authentication support and encrypted disk storage—including the ability to encrypt using customer-managed keys. Version 4.2 introduced client-side, field-level encryption.
The recent MongoDB 4.4 release added x509 authentication and integration with the AWS Identity and Access Management (IAM) system.
Despite all these technical advances, MongoDB databases are still targeted for attack. In July, thousands of MongoDB databases were destroyed by the “Meow” attack. This attack targets unsecured MongoDB, ElasticSearch and Redis databases and overwrites all data with the word “Meow." There is no ransom demand.
A recent Comparitech experiment showed that an unsecured MongoDB database could expect to be attacked on average several times every day. Today, if you create an unsecured MongoDB database on a cloud-based virtual machine, that database’s life expectancy is measured in hours!
Of course, MongoDB’s own Atlas database as a service platform is fully secured and immune from such attacks. Only systems configured manually on cloud-based virtual machines will exhibit these vulnerabilities. MongoDB would argue—and I would agree—that MongoDB Atlas is the easiest way of achieving a high level of cloud database security.
We might be seeing natural selection at work here. There’s no valid reason for creating an unsecured MongoDB database, and indeed it’s increasingly hard to do so. Most unsecured MongoDB databases are presumably development or test instances using obsolete versions of MongoDB code. As they are destroyed, perhaps they will be replaced by secured versions of the database.
Nevertheless, there is a lesson here for those who are deploying databases in the cloud. Historically, border security—company firewalls, in particular—have protected databases from external attack. In the new world of cloud-first databases, database security practices need to be bulletproof.