MongoDB Security Analysis and its Comparison with Relational Databases

Abstract — MongoDB databases seem to have taken the world by storm. It is a document-oriented NoSQL database. It is the most popular open-source database that allows users to query their data without having to learn and master SQL. This paper reviews the security features offered by MongoDB and how it performs compared to relational databases and security flaws.

Keywords — MongoDB, SQL, NoSQL, Security, Relational, Database

I. Introduction

II. Overview Of MongoDB

Fig. 1. MongoDB Document structure [10]

III. Features of MongoDB

A. Aggregation Framework

B. BSON Format

C. Sharding

Fig. 2. Sharding in MongoDB [11]

D. Adhoc queries

IV. Security Features of MongoDB

A. Authentication

MongoDB’s default authentication method is SCRAM (Salted Challenge Response Authentication Mechanism) i.e. SCRAM- SHA-1 (and SCRAM-SHA-256 for version 4.0). SCRAM is based on Internet Engineering Task Force(IETF) that defines best practices for authenticating users with passwords. SCRAM makes use of the provided credentials to match with the user’s name, password, and authentication database [3].

Another method called MongoDB-CR, similar to SCRAM verifies username and password against an authentication database. However, this functionality was removed from Version 3.0, and only older versions use it today. Both SCRAM and MongoDB-CR methods send passwords encrypted, and a different hash is generated for each new session so no one can misuse them.

MongoDB can also use external authentication protocols such as:

LDAP: With Lightweight Directory Access Protocol (LDAP), users log in to the system using their centralized passwords. LDAP is designed to help anyone locate and access the information they need in either a public or private network.

Kerberos: This is a secret key authentication protocol for server/client interactions. When using Kerberos, users can log in only once using an access ticket.

B. Authorization/Role-based security

Authorization can be activated using the — auth or the security-authorization setting. — auth enables authorization to control a user’s access to a database and its resources. This feature also enforces authentication after it is enabled. It requires all clients to verify their identities before being given access. There are two types of roles, built-in and user defined. Built-in roles include readWrite, dbAdmin, dbOwner, userAdmin, etc. User-defined roles are defined by the database administrator. Database administrators are given the responsibility of creating new users and assigning them roles. Administrators have the power of using MongoDB built-in​ ​roles​ ​or​ ​can​ ​create​ ​roles​ ​for​ ​a​ ​specific​ ​purpose. Access control is not enabled by default and needs to be enabled by using security, authorization settings. Limiting user roles limits the danger occurring from a single account being hacked [4].

C. Encryption

Fig. 3. MongoDB End to End encryption [5]

Mongo DB Enterprise provides a mechanism of native, storage-based symmetric key encryption at the file level to encrypt the data at rest. This entire process of database encryption is also called Transparent Data Encryption (TDE). MongoDB utilizes the Advanced Encryption Standard (AES) 256-bit encryption algorithm, an encryption cipher that makes use of the same secret key to encrypt and decrypt data. This methodology is known as Data-at-Rest Encryption. MongoDB does not offer any in-house features for application-level encryption. If we want to encrypt each field or document, MongoDB documentation suggests writing a custom encryption/decryption methods or using solutions that are created by one of their partners.

D. Auditing

Fig. 4. MongoDB Auditing [5]

The auditing framework captures administrative actions (DDL) such as schema operations as well as authentication and authorization activities. It also captures read and write (DML) operations to the database. Administrators can construct and filter audit trails for any operation against MongoDB, whether DML, DCL, or DDL without having to depend on third-party tools. For example, it is possible to log and audit the identities of users who read or retrieved specific documents, and any updates, inserts or deletes made to the database during their session. Auditing allows us to filter the output of a particular user, database, collection, or source location. This process generates a log that can be review for any security incidents. This log shows any security auditor that the company using MongoDB has taken the correct steps to protect its database from an intrusion and to understand the depth of any intrusion should one occur. MongoDB auditing allows us to fully track the actions of an intruder in the environment. Auditing is available only in MongoDB Enterprise. It’s not in the Community version. It is available in some other open-source versions of MongoDB such as the Percona Server for MongoDB [4].

V. MongoDB vs MySQL

· Deployment and Community support: MongoDB is owned and developed by MongoDB Inc. It is extremely simple to deploy MongoDB. It is also available for Web applications, SaaS, and Cloud applications. It can easily run on multiple platforms including Linux, Windows, and MacOS. MongoDB attracts users with its clean and simple architecture apart from its collaborative and helping community. MySQL is owned and developed by Oracle Corporation. MySQL can be installed manually from the source code. It is available for Web applications, SaaS, and Cloud applications. It can also run on multiple platforms including Linux, Windows, and MacOS. One advantage of MySQL is that people have been using it for quite some time and hence it has a strong community.

· Schema: MongoDB does not have any restrictions on schema design. The schema contains a collection of documents and it is not necessary to have any relation amongst those documents. The only restriction with this is supported data structures. Due to the absence of joins and transactions, frequent optimization of schema-based on organizational requirements is expected. MySQL needs clearly defined tables and columns and, every row in the table should have the same column. Because of this, there is not much space for flexibility in the manner of storing data. Development and deployment processes are slowed down as well due to the fact that even a little modification in the data model mandates the change in schema design.

· Querying Language: MongoDB uses un-Structured Query Language. In order to build a query in JSON documents, one needs to specify a document with properties. These properties should match the results we wish to achieve. It is typically executed using a very rich set of operators, linked with each other using JSON. MongoDB uses a “cascade” of operator/operand structures which is typically in the name:value pairs. MySQL uses the Structured Query Language (SQL) to communicate with the database. It is a very powerful language that consists mainly of two parts: Data Definition Language (DDL) & Data Manipulation Language (DML).

VI. MongoDB and MySQL Security Comparison

A. Base Security Model

B. Logging

C. Access Control

D. Code Injections

E. Integrity Models

VII. MongoDB Data Breach Case

Ransom Note by the hacker

Part of the ransom note, which is in broken English, is as follows:

“All of your data is backed up. You must pay 0.015 BTC to [REDACTED] 48 hours to recover it. After 48 hours of expiration, we will leaked & exposed all your data. In case of refusal to pay, we will contact the General Data Protection Regulation, GDPR & notify them that you store user data in an open form & is not safe. Under the rules of the law, you face a heavy fine or arrest & your base dump will be dropped from our server.” [7]

VIII. Security Issues in MongoDB

A. Authentication Weakness

B. Authorization Weakness

C. Javascript Injection Attacks

The scripting language used by MongoDB functions in JavaScript. Short scripts written in java-script are available as an internal command for developers. Java-script functions can be stored in the database in db.system.js collection. This collection is available to all the database users. So there is a high probability for attackers to inject their malicious scripts to this collection of functions. MongoDB ingests BSON data (Binary JSON) constructed using a secure BSON query construction tool. But in certain cases, MongoDB can also accept unserialized JSON and Javascript expressions like in the case of using the $where operator. JavaScript uses $where clause to evaluate records present in the collection. The result of this clause is read-only, so any changes in the database are not possible. But if $where clause is used without sanitizing the input values, chances of injection becomes higher. But if $where clause is used without sanitizing the input values, chances of injection becomes more.

Fig. 5. MongoDB Injection Attack [8]

D. Clear Text Data

E. Change User Password Function:

IX. MongoDB Security Checklist

· Enable Access Control and Enforce Authentication: Access control should be enabled, and an authentication mechanism must be specified. One can use the default MongoDB authentication mechanism or an existing external framework. Authentication will ensure that all clients and servers provide valid credentials before they can connect to the system. In clustered deployments, enable authentication for each MongoDB server.

· Configure Role-Based Access Control: First, a user administrator should be created. Then additional users should be created. A unique MongoDB user should be created for each person and application that accesses the system. Roles should be created that define the exact access a set of user’s needs. If possible, a principle of least privilege should be followed. Users should be created and assign the roles only that they need to perform in for the organization. No one should have elevated accesses.

· Encrypt Communication: MongoDB should be configured to utilize TLS/SSL for all incoming and outgoing network traffics. TLS/SSL must be used to encrypt communication between mongod and mongos components of a MongoDB client as well as between all applications and MongoDB.

· Encrypt and Protect Data: Starting with MongoDB Enterprise 3.2, the WiredTiger storage engine’s native Encryption at Rest can be configured to encrypt data in the storage layer. If WiredTiger’s encryption at rest is not used, MongoDB data should be encrypted on each host using filesystem, device, or physical encryption. MongoDB data should be secured using file-system permissions. MongoDB data includes data files, configuration files, auditing logs, and key files.

· Limit Network Exposure: We need to make sure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Only trusted clients should be allowed to access the network interfaces and ports on which MongoDB instances are available.

· Audit System Activity: All the access and changes to MongoDB database configurations and data should be tracked. MongoDB Enterprise includes a system auditing facility that can record system events (e.g. user operations, connection events) on a MongoDB instance. This audit facility should be activated in place. These audit records permit forensic analysis and allow administrators to verify proper controls.

· Run MongoDB with a Dedicated User: MongoDB processes should be run with a dedicated operating system user account. One should ensure that the account has permission to access data but no elevated permissions.

· Request a Security Technical Implementation Guide: The Security Technical Implementation Guide (STIG) contains security guidelines for deployments within the United States Department of Defense. Upon request, MongoDB Inc. provides its STIG, for situations where it is required. This copy can be requested for further information [9].

X. Conclusion

Acknowledgment

This paper and the research behind it would not have been possible without the exceptional support of Professor Dan Costa and Mr. Ajay Valecha (Teaching Assistant) at Carnegie Mellon University. I am grateful to them for sharing extensive knowledge of MongoDB databases and providing a vast set of study and research resources.

References

[1] “MongoDB Tutorial”, Java T Point, https://www.javatpoint.com/mongodb-tutorial

[2] “JSON and BSON”, MongoDB, https://www.mongodb.com/json-and-bson

[3] “The definitive guide to MongoDB security”, Opensource.com, https://opensource.com/article/19/1/mongodb-security

[4] “MongoDB Official documentation > Security”, MongoDB Documentation, https://docs.mongodb.com/manual/security/

[5] “Securing MongoDB Part 3: Database Auditing and Encryption”, MongoDB Blog, https://www.mongodb.com/blog/post/securing-mongodb-part-3-database-auditing-and-encryption

[6] “22,900 MongoDB Databases Affected in Ransomware Attack”, GlobalDots, https://www.globaldots.com/blog/22900-mongodb-databases-affected-in-ransomware-attack

[7] “Hacker Held 22,900 MongoDB Databases To Ransom By Threatening To Report Firms For GDPR Violations!”, PBSE Cyber News Group, https://www.cybernewsgroup.co.uk/hacker-held-22900-mongodb-databases-to-ransom-by-threatening-to-report-firms-for-gdpr-violations/

[8] “NoSQL Injection Attack”, SB Computter, https://sbcomputter.com/nosql-injection/

[9] “Security Checklist”, MongoDB Documentation, https://mongoing.com/docs/administration/security-checklist.html

[10] “What is MongoDB — Working and Features”, GeeksforGeeks, https://www.geeksforgeeks.org/what-is-mongodb-working-and-features/

“Sharding”, MongoDB Documentation, https://docs.mongodb.com/manual/sharding/

Manager, Insights & Data AI pillar at Capgemini, North America. MSIT (Business Intelligence and Data Analytics) student at Carnegie Mellon University.