Some 30,000 instances of MongoDB are accessible without authorization over the Internet because of a failure by database administrators to properly configure them, a security researcher warned this week.
In total, nearly 600 terabytes of data are exposed on the public Internet as a result of such configuration errors, John Matherly said in a blog post.
A Surprising Find
According to Matherly, he stumbled across the 30,000 exposed MongoDB instances when using his specialized search engine, Shodan, to look for databases that were accessible from the Internet without authorization. The sheer number of exposed databases was somewhat surprising, considering that default MongoDB instances are supposed to listen only to localhost and have done so for a while.
So Matherly downloaded multiple older versions of the database to try to determine when the default configuration was changed to listen in to external connections. He traced the problem back to a configuration issue that was first highlighted in 2012 by security researcher Roman Shtylman. At that time, the security researcher had noted that the default install of the database was set to listen to external connections, thereby exposing users to potential attacks. “The default should be to lock down as much as possible and only expose if the user requests it,” Shtylman said.
Unauthenticated Access to MongoDB
The issue is apparently not unique to MongoDB installations. Similar vulnerabilities exist with other NoSQL database installations, most notably Redis, Matherly said. The problem has to do with the practice of using insecure default configurations of NoSQL databases that permit unauthenticated access to the database.
Newer NoSQL databases do not always come with the secure default settings that are present in MySQL, PostgreSQL and other relational database management products. Many of the older products, for instance, are set to listen in to the local interface only and to provide for some form of authorization by default. “This isn’t the case with some of the newer NoSQL products that started entering [the] mainstream fairly recently,” Matherly wrote.
Majority of Exposed Instances Are Cloud-Hosted
Matherly also discovered that the vast majority of the publicly accessible database instances are currently operating in the cloud. Based on the search with Shodan, the most popular destinations for hosting improperly configured MongoDB instances appear to be cloud vendors like Amazon, Digital Ocean, Linode and OVH.
According to the security researcher, cloud-hosted instances were more vulnerable overall compared to on-premises solutions. One of the reasons could be the fact that cloud-hosted server images do not get updated as frequently as systems that are deployed on-premises, the security researcher theorized.
Unaware of Risk
Many organizations are running vulnerable, outdated instances without being aware of the risk, Matherly said. When reviewing the results, the security researcher discovered that nearly 40 percent of the vulnerable instances were running MongoDB 1.8.1, a very old version of the database.
In an official MongoDB blog post, Kelly Stirman, the vice president of strategy at MongoDB, said the issues highlighted by Matherly have to do almost entirely with improper implementation of the technology by administrators.
Stirman noted that the default network access setting for the most popular installer for the database is limited to localhost. MongoDB also provides a security checklist that details how organizations can limit network exposure depending on where their service is hosted.
Organizations that follow the best practices for MongoDB and similar databases should be in a better position to protect themselves — and their data — from vulnerabilities. Constantly evaluating relevant security practices can also ensure that these problems are minimized.