MongoDB faced its worst-ever public relations challenge earlier this year when a spate of ransomware attacks plagued tens of thousands of Mongo instances.
These ransomware attacks were aimed at MongoDB databases that were configured without any authentication mechanisms and which were located on the public internet. It had long been known that large number of MongoDB databases were insecurely configured: back in 2015 about 40,000 such databases were identified.
It’s important to realize that we are not talking about some sort of obscure vulnerability here – these MongoDB databases were configured with NO passwords at all, and were easily found listening on the default port (27017) on publicly-accessible servers. This is worse than leaving your front door unlocked – it’s more akin to leaving all your doors and windows wide open and placing a “come and take what you want” sign on your lawn.
These insecure databases are created when a user installs the database and fails to configure an administrative account with a password. Some MongoDB installers will establish this configuration by default, though most modern versions of MongoDB will not allow unauthenticated connections from external systems. However, for reasons that are as much sociological as technical, it became increasingly common for MongoDB servers to be installed without authentication.
Although most non-secure installations were probably test or development instances, some contained sensitive information. The CloudPets.com production database for instance was listening on the default port with no authentication, allowing a malicious hacker to steal 10GB of private information. Emory Healthcare reported a similar breach for the same reason.
In January 2017, a wave of ransomware attacks hit insecure MongoDB databases. The attacks scanned the internet for insecure MongoDB databases and, when found, erased the database contents and demanded a bitcoin ransom to restore the information. Within a week, at least 30,000 MongoDB databases were attacked. In most cases the databases needed to be restored from backup – in many cases paying the ransom did not result in a return of data.
Why did so many MongoDB database come to be insecure? It’s partly because the MongoDB installers – especially earlier installers – made it very easy to set up an unsecured database instance. The extra steps required to enable authenticated access could easily be bypassed and, human nature being what it is, many users simply took the quickest and easiest installation path. In the developer-dominated web stacks where MongoDB flourished, the traditional DBA concerned with security and compliance was often absent and so the initial insecure installations could find their way into production deployments.
Happily, MongoDB database vulnerability is a non-issue providing common sense and clearly documented best practices are observed. MongoDB users can be authenticated using a username/password mechanism based on the SCRAM-SHA-1 standard or an x.509 certificate. The commercial MongoDB Enterprise product is further capable of authenticating via LDAP or Kerberos, allowing authentication to integrate with Enterprise-wide authentication systems such as Active Directory.
Communication between clients and MongoDB servers or between MongoDB servers in a clustered environment can be encrypted by TLS/SSL – the same mechanisms that provide secure communications between web browsers and web servers. This mechanism prevents eavesdropping on the networks connection and optionally certificate-based validation of the server’s identity.
By default, MongoDB data files are stored unencrypted, which means that an attacker that gains access to the database host can read data in these files without a database connection. This is a pretty common situation for all databases: the security of the database is often only as good as the security for its host. However, MongoDB enterprise allows data in the WiredTiger storage engine to be encrypted to close this vulnerability.
Correctly configured, MongoDB is no less secure than any enterprise database. While default configurations and sloppy installation procedures can leave the database vulnerable, standard database security best practices are fully supported. While there may be many valid workloads for which MongoDB is not ideal, concerns about security should not prevent you from choosing MongoDB.