Reproduction of MongoDB Unauthorized Access Vulnerability

Cause of the Incident#

Continuously organizing notes

Reference articles:

Originally, I was planning to refer to other articles and set up a test using docker myself, but unexpectedly, I found the keyword "shodan" in the search results.

0x00 Introduction#

MongoDB is a database based on distributed file storage. It is written in C++ and aims to provide a scalable and high-performance data storage solution for web applications.
MongoDB is a product that falls between relational databases and non-relational databases. It is the most feature-rich and most similar to a relational database among non-relational databases.

0x01 Vulnerability Impact#

When starting the MongoDB service without adding any parameters, it does not have authentication enabled by default. Users who log in can perform any operations on the database (such as adding, deleting, and modifying data) without a password through the default port, and can also access the database remotely.

0x02 Cause of the Vulnerability#

When MongoDB is first installed, it already has an admin database, which is initially empty and does not contain any information related to permissions. Even if the --auth parameter is added when starting mongod, if no user is added to the admin database, no authentication is performed and any operations can be performed (regardless of whether --auth is used) until a user is added to admin.system.users. The core of reinforcement is that MongoDB's authentication and authorization services only take effect after a user is added to admin.system.users.

0x03 Vulnerability Reproduction#

Searching for Corresponding Data Using Shodan#

Search for unauthorized MongoDB databases using a certain keyword:

Scanning with MSF#

use auxiliary/scanner/mongodb/mongodb_login
set rhosts xxx.xxx.xxx.xxx
set threads 20
exploit

As shown in the figure, you can see the scanned servers that are unauthorized.

You can then connect using tools such as navicat.

Unexpectedly, it turned out to be a hacked database. The hacker demanded a payment of 0.1 bitcoin within 7 days. Let us wish the owner of this database well.

0x04 Defense#

Change the default port.
Do not expose the service to the public network.

vim /etc/mongodb.conf
bind_ip = 127.0.0.1

Disable the HTTP and REST ports.

0x05 Using Proxychains for Proxying#

For the old version of proxychains, use the command:

apt-get install proxychains -y

to install. The current version is v3.1.

The new version of proxychains ng supports bypassing the local proxy function.

If the old version is installed, use these two commands to download it cleanly:
apt-get remove proxychains -y
rm /etc/proxychains.conf

git clone https://github.com/rofl0r/proxychains-ng
cd proxychains-ng
./configure --prefix=/usr --sysconfdir=/etc
make && make install
make install-config
cp proxychains-ng/src/proxychains.conf /etc/proxychains.conf

Then edit the configuration file and add the sock5 proxy (using a little airplane).

vim /etc/proxychains.conf

In vim, press GG in command mode to jump to the end.

Delete the original sock4 proxy.

Add the specified IP address with port 1080. If it is local, use 127.0.0.1.

I am using a little airplane on my laptop as a proxy for my Raspberry Pi, so I use the IP address of my laptop.

And open the options settings for the little airplane, allowing connections from the local network:

Now you can add the proxychains4 statement before common commands to achieve the effect of proxying.

For example, to access google.com: proxychains4 curl https://www.google.com

ping google

Issues Encountered When Using Proxychains to Proxy MSF#

So, can we directly proxy MSF?

First, in msf, you can directly set the socks5 proxy:

set proxies socks5:192.168.1.7:1080

However, this method is only applicable to reverse proxies used when connecting with reverse_tcp, etc.

(Understanding may be incorrect, welcome to point it out in the comments)

So, what happens if we directly use proxychains4 msfconsole?

As you can see, my old friend postgresql's port 5432 is being proxied by the proxy, which directly causes a connection failure.

And if I don't use proxychains and use the new version, it is because the new version has the ability to proxy locally.

Continue editing the /etc/proxychains.conf file.

You can see that many examples are given.

The most likely one to be used is the statement localnet 127.0.0.0/255.0.0.0.

But after removing the comment for this statement, it did not improve the problem. Upon closer inspection, it was found that postgresql was connecting to localhost:5432 instead of 127.0.0.1:5432.

And the localnet statement directly followed by localhost will cause an error.

It may also be that I did not find the correct usage. If anyone knows, please let me know in the comments.

Here is a point of knowledge: when initializing the msf database using mmsfdb init, the default location of the configuration file is:

/usr/share/metasploit-framework/config/database.yml

As you can see, it connects to localhost in the file.

Currently, to use proxychains4 to proxy msf and allow msf to run normally, the following solutions are available:

Either modify the postgresql configuration to connect to 127.0.0.1 instead of localhost.
Or manually connect to the 127.0.0.1 database in msf.

End of the article.