Last updated at Wed, 30 Aug 2017 00:16:12 GMT
This is the 4th in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out the training page at www.rapid7.com/services/training-certification/penetration-testing-training.jsp
Preface
As penetration testers, we are always looking for commonly used services that offer us (and attackers) easy ways into networks. Some of these easy wins include Tomcat, Java RMI instances with class loaders enabled, vulnerable IPMI instances, and or databases poorly configured or misconfigured. These entry points are not theoretical or what could potentially happen. These issues are what does happen over and over and over on penetration test.
Today we are going to talk about an open-source NoSQL database known as MongoDB. By default, this database does not require a password to authenticate to it. Even though this database only listens on localhost by default, I've found this service listening on a externally accessible port more than a few times. So much in fact I'm now blogging about it.
What is it?
What is NoSQL? No, it's not a protest against SQL; it's a different type of database solution. One of the problems with NoSQL is there is no authentication associated with most types of NoSQL solutions. Besides MongoDB, other NoSQL solutions include Redis, and Apache Cassandra.
MongoDB is one of the more popular NoSQL solutions. As a result, it is something we have been finding frequently on our penetration tests. And as it is a type of database, simply gaining access to it can often be considered a compromise. There have been a number of data breaches due to improper use of MongoDB. There were 93 Million Mexican voters who had their data breached due to a MongoDB being misconfigured.
A dating site had its users compromised because of a misconfigured MongoDB instance, and 13 million MacKeeper users were also compromised, yep you guessed it, by MongoDB misconfiguration.
How do so many people misconfigure their databases you ask? Well its simple: the default install requires no password. This is done with the intention that the database does not listen externally on the system. However, most users want it to listen externally so what do they do? They make it listen externally and go about their business, happy that their software works, and live happily ever after. That's when the big bad wolf hacker comes sniffing around trying to huff and puff and access your database that does not have a password.
As you might imagine it does not require a lot of skill to access a database with no password. In fact, you probably logged into your phone or computer in order to read this blog, and that required more effort than it does to access these databases. Let's take a look at some of the ways hackers do it.
How to find it?
MongoDB runs on a default port of 27017. If you don't know what a port is, imagine a computer system as an office building. The ports are doors and windows into the building. MongoDB is window 27017. In order to find out if this window, I mean port, is open on a system, you can scan a network using tools such as masscan, shodan, nmap, metasploit, and nosqlmap.py. For example, to find it using nmap you can run the following commands:
nmap -Pn -p 27017 --script mongodb-databases x.x.x.x
If you wanted to use Nosqlmap.py in order to find MongoDB instances you could use the following command:
nosqlmap.py
Then go through the menu options as demonstrated in Figure 2:
Lastly is a way to find MongoDB using Rapid7's very own Metasploit. The Metasploit module that will help in this instance is the following:
auxiliary/scanner/mongodb/mongodb_login
The Metasploit commands shown in Figure 3 are as follows:
use auxiliary/scanner/mongodb/mongodb_login
show options
set rhosts x.x.x.x
exploit
Now that we have found MongoDB wide open on a network what do we do now, Brain?
Well Pinky, now we take over the WORLD … err access the database.
How to access it?
At this point accessing a database can be done any number of ways. We could simply use the MongoDB client as demonstrated in Figure 4:
We could use a third party GUI client if you like to click your way around databases. Once such client is Robomongo as can be seen in Figure 5.
Additionally, we could use NoSQLMap to access data from the database as well. NoSQLMap provides the following options to access the database also seen in Figure 6.
- Get Server Version and Platform
- Enumerate Databases/Collections/Users
- Check for GridFS
- Clone a Database
- Launch Metasploit Exploit for Mongo < 2.2.4
How to exploit it?
If you have been following along closely you might have noticed versions 2.2.3 and below are vulnerable to more than just accessing them. Specifically, versions 2.2.3 and below makes use of the “nativeHelper” feature in the spidermonkey MongoDB implementation. As it stands this only affects 32 bit Linux installs of MongoDB 2.2.3 and below. The Metasploit module for exploiting this is as follows:
exploit/linux/misc/mongod_native_helper
Additionally, versions 2.2.3 and below are also vulnerable to NoSQL injection. There is a mMetasploit module that can be used against the web interface. The Metasploit module used for exploiting this is as follows:
auxiliary/gather/mongodb_js_inject_collection_enum
Note: Additional security risks
Even when it's secured, if an attacker or pen tester gets on the box they will will be able to extract the password in clear text. This is because the password is stored in the mongodb.conf file in clear text. There is currently nothing that can be done about this.
This is one of the ways companies are getting compromised these days. If you want to learn more techniques like this, look out for the rest of our “Pentesting in the Real World” series, and sign up for our assault class where we will teach you how to identify issues and how to exploit those issues to gain access and / or information.