2017-01-04 Critical security issue in MongoDB

It has been reported and confirmed that some many unsecured MongoDB databases have been scanning and vandalizing around the world. This attack affects only those databases which maintain default configurations, which leave the database open to external connections via the Internet.

Find more information about the issue.

Affected platforms

Bitnami Security Team has checked that prior versions to Bitnami’s MongoDB with Replication 3.4.1 are vulnerable which left their default configuration. It affects to the following platforms:

• Google Cloud Platform

• Azure Marketplace

Non-affected platforms

The following platforms and images are not affected by this issue:

• Bitnami Single Cloud Images (MongoDB configuration without replication)

• Bitnami Native Installers

How to patch it

If your installation is affected, it is strongly recommended to take the following actions:

• Restricting external access to default port 27017

• Enabling authentication to secure your installation

• Restoring your database

Restricting access to port 27017

Ensure that the installations are not accessible from the public Internet by restricting access to port 27017, or removing the public IP addresses from all MongoDB nodes. Learn how to close the server ports.

Enabling authentication to secure your installation

The proposed approach to ensure your installation consists of two phases:

• Enabling admin authentication to the replica set.

• Enabling internal authentication with a keyfile.

These are the steps you need to follow to make sure that both the communication between members of the replica set and the connection with clients are safe:

• Connect to the server using a SSH client. For more information check these instructions

• Run the following commands in the primary node to generate a keyfile:

    $ openssl rand -base64 756 > ~/mongo.key
    $ sudo mv ~/mongo.key /opt/bitnami/mongodb/conf/mongo.key
    $ sudo chmod 400 /opt/bitnami/mongodb/conf/mongo.key
    $ sudo chown mongo:mongo /opt/bitnami/mongodb/conf/mongo.key
  

• Copy the keyfile into the /opt/bitnami/mongodb/conf/mongo.key path of each node of the replica set:

    $ ls -la /opt/bitnami/mongodb/conf/mongo.key
  

You can also print the content of this file and copy it in your clipboard to paste in a different node:

• Check the permissions are set correctly:

    $ -r-------- 1 mongo mongo 1024 Jan 10 12:02 /opt/bitnami/mongodb/conf/mongo.key
  

• Run the following commands in case that the permissions are not set as expected:

    $ sudo chmod 400 /opt/bitnami/mongodb/conf/mongo.key
    $ sudo chown mongo:mongo /opt/bitnami/mongodb/conf/mongo.key
  

• Shut down each node of the replica set. Start to shutting down the secondary nodes, including any arbiter node. End this procedure shutting down the primary node. Run the following command in each instance:

  NOTE: The primary node must be the last member of the replica to shut down in order to avoid potential rollbacks.

    $ mongo admin --eval "db.shutdownServer()"
  

• Run the following commands to enable the authorization and keyfile options in the /opt/bitnami/mongodb/conf/mongodb.conf file (repeat this action in each node of the replica set):

    $ sudo sed -i 's/authorization: disabled/authorization: enabled/' /opt/bitnami/mongodb/conf/mongodb.conf
    $ sudo sed -i 's/#keyFile: replace_me/keyFile: \/opt\/bitnami\/mongodb\/conf\/mongo.key/' /opt/bitnami/mongodb/conf/mongodb.conf
  

• Check that the /opt/bitnami/mongodb/conf/mongodb.conf file of each node shows the following lines as below:

    # security options
    security:
        authorization: enabled
        keyFile: /opt/bitnami/mongodb/conf/mongo.key
  

• Restart each node:

  $ sudo service bitnami restart
  

At this point, all nodes should be started again.

• Access the primary node and create a new user with administrator privileges:

    $ mongo
    admin = db.getSiblingDB("admin")
    admin.createUser(
        {
        user: "root",
        pwd: "changeme1",
        roles: [ { role: "root", db: "admin" } ]
        }
    )
  

• Exit and connect to it database using the administrator credentials:

    $ mongo admin -u root -p
  

NOTE: From now, you need to authenticate as user administrator to connect to your database.

• (Optional): Create a new user with the “clusterAdmin” role in the primary node. This step is highly recommended to grant the access to replication operations:

    db.getSiblingDB("admin").createUser(
        {
        "user" : "clusteradmin",
        "pwd" : "changeme2",
        roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
        }
    )
  

• (Optional): Create a new user with restricted privileges to ensure an existing database. Follow these instructions

Restoring your database

The last step is recovering the database using the oplog file, which keeps a rolling record of all operations that modify the data stored in your databases. Check how to recover your database using the MongoDB Oplog