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 website , it's being used by large corporations such as Disney, Forbes, MTV, UK Government to
name just a few.
So, it was time to fire up a test VM, and download the latest version to have a 'play'.
For those of you not familiar with MongoDB, below are the pertinent points to bring you up-to-speed:
Ok, so what do you need to know to hack/test it? Its default ports are as follows:
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 > 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:
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 < Msf::Auxiliary
include Msf::Auxiliary::Scanner
include Msf::Exploit::Remote::Tcp
include Msf::Auxiliary::Report
def initialize(info={})
super(update_info(info,
'Name' => 'MongoDB Enum Utility',
'Description' => %q{
Kirky's MongoDB Enumerator},
References'=>
[[ 'URL','http://www.mongodb.org/display/DOCS/Mongo+Wire+Protocol' ],[ 'URL','http://www.mongodb.org/display/DOCS/Implementing+Authentication+in+a+Driver' ]],
'Author' => [ 'kirky' ],
'License' => 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 => e
print_error "MongoDB Server: #{e.to_s}"
return
end
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 << requestID #MWP Request ID
packet << "\xff\xff\xff\xff" #MWP responseTo
packet << "\xd4\x07\x00\x00" #MWP Opcode 2004 (OP_QUERY)
packet << "\x00\x00\x00\x00" #MWP OP_QUERY flags
packet << "\x61\x64\x6d\x69\x6e\x2e\x24\x63\x6d\x64\00" #fullCollectionName database=admin,collection=$cmd (admin.$cmd)
packet << "\x00\x00\x00\x00" #MWP numberToSkip (0)
packet << "\x01\x00\x00\x00" #MWP numberToReturn (1)
packet << "\x1c\x00\x00\x00" #MWP Doc Length
packet << "\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
end
Given the lack of security with mongodb with the default install, basic security hardening best practices should include:
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.