July 23, 2015 By Jaikumar Vijayan 2 min read

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.

More from

NIST’s role in the global tech race against AI

4 min read - Last year, the United States Secretary of Commerce announced that the National Institute of Standards and Technology (NIST) has been put in charge of launching a new public working group on artificial intelligence (AI) that will build on the success of the NIST AI Risk Management Framework to address this rapidly advancing technology.However, recent budget cuts at NIST, along with a lack of strategy implementation, have called into question the agency’s ability to lead this critical effort. Ultimately, the success…

Researchers develop malicious AI ‘worm’ targeting generative AI systems

2 min read - Researchers have created a new, never-seen-before kind of malware they call the "Morris II" worm, which uses popular AI services to spread itself, infect new systems and steal data. The name references the original Morris computer worm that wreaked havoc on the internet in 1988.The worm demonstrates the potential dangers of AI security threats and creates a new urgency around securing AI models.New worm utilizes adversarial self-replicating promptThe researchers from Cornell Tech, the Israel Institute of Technology and Intuit, used what’s…

Passwords, passkeys and familiarity bias

5 min read - As passkey (passwordless authentication) adoption proceeds, misconceptions abound. There appears to be a widespread impression that passkeys may be more convenient and less secure than passwords. The reality is that they are both more secure and more convenient — possibly a first in cybersecurity.Most of us could be forgiven for not realizing passwordless authentication is more secure than passwords. Thinking back to the first couple of use cases I was exposed to — a phone operating system (OS) and a…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today