Mongodb - Security Weaknesses in a typical NoSQL database

Over the last year or so, I’ve noticed 2 ports appearing more frequently during internal penetration tests, namely 27017/tcp and 28017/tcp. These can be easily missed if full port scans are not performed.

A quick service scan revealed this as ‘MongoDB’. I had heard of it before, but never really taken the time to look at it in any great detail. After a couple of hours of research, I realised this database was

coming up in the world. Looking at their Production Deployment Use Cases on MongoDB’s

name just a few.

So, it was time to fire up a test VM, and download the latest version to have a ‘play’.

<a></a>

For those of you not familiar with MongoDB, below are the pertinent points to bring you up-to-speed:

10Gen brought out the first release in 2007, so its not that old.

It’s a “document-orientated” database (otherwise known as a NoSQL database). 

Typically, NoSQL DB’s use XML, YAML, JSON, and BSON to encode the data. MongoDB uses Binary JSON (BSON). 

NoSQL databases have their own terminology that is different from typical relational databases such as MSSQL and MySQL:

Document = Row or Record

Collection = Table or View

Field = Column

So, a typical NoSQL database collection (table) holds one or more “documents” (records). Each document can have one or more fields (columns).

It’s being used more and more in the production of agile applications i.e. quick to develop and deploy and often used in “big data” type projects. These can include banking applications and document storage as examples.

Ok, so what do you need to know to hack/test it? Its default ports are as follows:

28017 - This is the default port for the web status page. This is always accessible at a port that is 1000 greater than the port determined by

So, playing with the most recent version from their web site, possible attack vectors I can think of are as follows (there may be more):

1)      Authentication Weakness – By default the DB installs with NO password credentials! Reading the MongoDB manual the MondoDB developers have put the onus of security entirely in the hands of the application developers and running it

in a trusted environment. I thought lessons had been learnt with the older more mature RDBMS DB cousins and their historic authentication weaknesses…..its seems not.

2)      Authorization Weaknesses – Any created user has read-only access to the WHOLE  database. That essentially means that once you have a user, you have provided access by default to everything stored in the database….not the most secure.

3)      Admin Authorization Weakness – A user with access to the Admin database has read/write access to everything! There is no granularity. We already know that by default there is no Admin password, so….guess what…by default we have access

to everything !

4)      Clear Text – All data is sent in the clear, so the data can be captured in an ARP Poison attack or other such MITM attack.

5)      Multiple Interfaces Weakness – By default the service will bind to ALL available interfaces….not so good if you’re installing it in a dual-homed environment ….you could essentially expose the whole database to a less trusted DMZ

if you wern’t careful!

6)      No Encryption – Currently there is no data encryption.

7)      NoSQL infers it’s safer than RDBMS’s which are vulnerable to SQL Injection –

Therefore it’s being deployed with this inference, assuming more security. The above shows this isn’t the case!

Certainly the times I have seen this during internal engagements, it has been installed in default mode i.e. NO PASSWORD, READ/WRITE ACCESS.

Clearly the developers using it tend to want to get a working application up and running as the priority rather than looking at the security, from my experience.

So how do you go about testing it?

There are several clients available from the mongoDB web site which include the Mongodb shell e.g. curl http://downloads.mongodb.org/linux/mongodb-linux-i686-2.2.2.tgz &gt; mongo.tgz

This is currently 52.2MB in size.

In terms of security tools, there isn’t a lot out there at the moment. Metasploit does have a scanner:

use  auxiliary/scanner/mongodb/mongodb_login

This is good for checking passwords when authentication is enabled, but it didn’t tell me if default conditions were met i.e. the mongodb had no credentials.

Therefore, I wanted to amend the above tool to perform the following functions:

Finds hosts with TCP port 27017 open   

Checks if authentication is required or not

Attempt to login to Admin DB with no authentication.

List available databases

The metasploit script below performs the above function:

#### This file will look for MongoDB databases on the network

#### and determine if authentication is requried or not.

#### If it isn't then it will enumerate basic information from it.

#### Makes use of the Mongo Wire Protocl (MWP) on default TCP port 27017.

#### Written by: David Kirkpatrick

require 'msf/core'

class Metasploit3 &lt; Msf::Auxiliary

  include Msf::Auxiliary::Scanner

  include Msf::Exploit::Remote::Tcp

  include Msf::Auxiliary::Report

  def initialize(info={})

    super(update_info(info,

    'Name' =&gt; 'MongoDB Enum Utility',

    'Description'  =&gt; %q{

     Kirky's MongoDB Enumerator},

     References'=&gt;

     [[ 'URL','http://www.mongodb.org/display/DOCS/Mongo+Wire+Protocol' ],[ 'URL','http://www.mongodb.org/display/DOCS/Implementing+Authentication+in+a+Driver' ]],

     'Author'       =&gt; [ 'kirky' ],

     'License'      =&gt; MSF_LICENSE

      ))

   register_options(

   [

     Opt::RPORT(27017),

     OptString.new('DB', [ true, "Database to use", "admin"])

    ], self.class)

     deregister_options('RHOST')

   end

   def run_host(ip)

     print_status("Scanning IP: #{ip.to_s}")

     begin

     connect

    print_good("MongoDB Server #{ip.to_s} alive with no authentication!!!")

    show_dbs(ip)

    rescue ::Exception =&gt; e

    print_error "MongoDB Server: #{e.to_s}"

    return

  end

# Mongo Wire Protocol Packet

def show_dbs(ip)

requestID = Rex::Text.rand_text(4)

packet = "\x3f\x00\x00\x00"     #MWP message length (63)

packet &lt;&lt; requestID             #MWP Request ID

packet &lt;&lt; "\xff\xff\xff\xff"    #MWP responseTo

packet &lt;&lt; "\xd4\x07\x00\x00"    #MWP Opcode 2004 (OP_QUERY)

packet &lt;&lt; "\x00\x00\x00\x00"    #MWP OP_QUERY flags

packet &lt;&lt; "\x61\x64\x6d\x69\x6e\x2e\x24\x63\x6d\x64\00" #fullCollectionName database=admin,collection=$cmd (admin.$cmd)

packet &lt;&lt; "\x00\x00\x00\x00"    #MWP numberToSkip (0)

packet &lt;&lt; "\x01\x00\x00\x00"    #MWP numberToReturn (1)

packet &lt;&lt; "\x1c\x00\x00\x00"    #MWP Doc Length

packet &lt;&lt; "\x01\x6c\x69\x73\x74\x44\x61\x74\x61\x62\x61\x73\x65\x73\x00\x00\x00\x00\x00\x00\x00\xf0\x3f\x00"    #MWP query listDabases

sock.put(packet)

response = sock.recv(1024)

name = response.scan(/name.....(.*?)..sizeOnDisk/)

dbname = name.join(",")

print_status("List of Databases on #{ip.to_s}:- #{dbname}")

disconnect()

end

Given the lack of security with mongodb with the default install, basic security hardening best practices should include:

Disabling the default status page – using the ‘nohttpinterface’ option to turn off the 28017 port.

Use a different port – using the ‘port’ option

Do not enable REST in production environments – don’t use ‘rest’ option

Bind the mongodb process to only one interface/IP – using the ‘bind_ip’

Don’t run mongodb daemon as root

Disable anonymous access – using the ‘auth’ option

Encrypt data - “To support audit requirements, you may need to encrypt data stored in MongoDB. For best results you can encrypt this data in the application layer, by encrypting the content of fields that hold secure data.”

Encrypt communication – Recommended to use SSL

Trusting the security of the database entirely on the application and how well it's written will continue to be a security issue, history has shown that.

So, if you haven’t added this to your list of top attack vectors, I’d recommend starting to look for it in your port scans. At the moment, the instances I’ve seen it on the network, the majority of times it’s a totally unprotected database.

If the developers of mongodb continue to leave the onus of the security to the people using it, I guess it will continue to be an easy target! I can’t wait till they start adding commands to interact with the operating system! That will be fun! It's certainly

one to keep an eye on to see how it develops.