juanjo tugores - Fotolia
A massive misconfiguration issue affecting the NoSQL MongoDB database has reportedly rendered 30,000 instances...
publicly accessible and insecure. A security researcher determined that, as a result, 25 million user accounts have been exposed, including more than 10 million accounts for the Mac OS X optimization software MacKeeper. What configuration issue caused this exposure, and could it affect other database programs?
In the era of plug and play, rapid application development and one-click installations, nobody seems to have time to read the manual. In the case of the popular open source NoSQL MongoDB database, this has resulted in at least 35,000 instances of insecure databases being deployed on the Internet. The data, estimated to total around 684.8 terabytes, is fully accessible by anyone; there is no need to hack into the database using malware or sophisticated attack tools. Researcher John Matherly found the vulnerable data purely by doing a random port:27017 search using the Shodan search engine, which explores the Internet for any type of device connected to the Internet -- by default, MongoDB listens on TCP port 27017.
It appears the problem is getting worse. Matherly first ran a search for unauthenticated MongoDB instances in July 2015 and found nearly 30,000. When he recently reran the search, the number had increased to 35,000. Another security researcher, Chris Vickery, found information exposed in these databases from various well-known apps and services. The sensitive data included 13 million user accounts associated with the OS X optimization program MacKeeper, 2.6 million accounts for the video chat app OkHello, 2.5 million for the online gaming site Slingo and over half a million for the fitness app iFit -- some 25 million user accounts in total.
This huge exposure of user data is not due to a vulnerability in MongoDB, but the way developers have configured it to run, despite the MongoDB documentation providing detailed instructions on how to properly configure the system and information about the security capabilities available. As mentioned, 27017 is the default port for MongoDB database instances and needs to be protected at the network layer so it's not exposed to the Internet. Developers or administrators need to restrict MongoDB access to localhost only, and only remotely access the database over a VPN connection, but as Matherly discovered many are leaving the database publicly accessible by not blocking incoming connections to the server's port 27017 from the Internet.
BizApps Today looks at why the MongoDB database has become an appealing choice for enterprises, and what challenges lie ahead for the company. Alt text: Find out why the NoSQL MongoDB database is gaining traction with
MongoDB versions 3.0 and newer now only listen to localhost so they don't accept remote connections from the Internet, but it appears as if developers and administrators are actively or unwittingly circumventing this control, as the largest number of exposed MongoDB database installations are running version 3.0.7. It could be that when developers have upgraded they've continued to use their existing, insecure configuration files. Worse still, is that if the new, more secure default configuration broke existing applications, developers may well have deliberately modified it to something less secure to quickly restore operations. For example, if MongoDB were deployed on Amazon Elastic Compute Cloud (EC2), administrators would specifically have to open up port 27017, as ports are closed by default on EC2. A correct approach would be to only expose port 27017 to servers within the Virtual Private Cloud by using security groups. Either way, not enough people seem to be reading the manual or version release notes, which say: "In 3.0, the localhost exception changed so that these connections only have access to create the first user on the admin database. In previous versions, connections that gained access using the localhost exception had unrestricted access to the MongoDB database instance."
Sadly, similar examples of insecure configurations probably exist for other types of database: Security company BinaryEdge, based in Switzerland, identified more than 1.1 petabytes of data exposed online due to misconfigured MongoDB, Redis, Memcached and Elasticsearch databases. That's an incredible amount of data from just four different database technologies.
Developers and administrators need to research and understand how to securely configure and deploy any database that is potentially accessible via the Internet. Most default settings are not secure enough for a production environment; they are generally set to make the initial installation straightforward. Even where default settings are already fairly restrictive, developers often loosen or disable them to make development easier, forgetting to reapply them in the production release. Databases need to be hardened and made Internet-ready by experienced or properly trained database administrators before being connected to the Internet if sensitive data is to remain secure. They also need protection in the form of a correctly configured firewall to monitor and control inbound and outbound traffic.
Evaluate the strength and weaknesses of top-rated database security tools
Learn about the ways database security tools can boost your enterprise security
Find out how IT teams use graph databases to find business connections
Dig Deeper on Database Security Management-Enterprise Data Protection
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading