MTFBWY if the weakest link of your network is your MongoDB instance.

We often talk profoundly about how we protect our internet facing assets. The false sense of security often comes from the lack of understanding of our own exposure. In the past couple of years, working with many customers I have realized that no one possess an absolutely current inventory of assets. You may attribute the conundrum of maintaining an asset inventory to the frequent acquisition and mergers, never ending plans to migrate to cloud and deliberate violation of policies by developers, but the reality is that all of us have enough ports open to the internet. The wall we envisioned is in fact a net with proliferating holes.

With all respect to those who said cloud will help organizations setup enterprise class service with a snap of a finger, it also helps them dig enterprise class holes on the network without another snap of a finger. Imagine what happens when you forget the basics on the placement of a database server in network? Imagine what might happen if you keep the DB in the DMZ?

Yeah, It happens.

And here is the story of what happened:

The discovery…

One fine Saturday morning (which people from the same time zone often categorize as ‘afternoon’), I decided to perform a recon on one domain [let’s say ( somedomain.tld ). I happened to stumble up on a MongoDB server which belongs to the same domain on shodan.io. Just out of curiosity I tried the following query on shodan.io.

The result was quite surprising. A handful of servers in the first results page itself seemed to have no authentication in place!

A MongoDB server with anonymous authentication

The next logical step I had to take was to verify the access to one of these servers. So I downloaded the MongoDB Compass client. and tried to access the same database as an anonymous user, supplying no credentials.

Mongo DB Connection settings

And there you go, full access to the server with all the option to create, delete, retrieve, modify anything on the same.

Unauthenticated access to a MongoDB server

Exploration continues…

Well and good. So what? There are a handful of MongoDB servers exposed to network, with no authentication in place. So what? The skeptic in me started questioning myself and I had to find other ways to convince myself that this is not an isolated incident.

So I started browsing through the result pages.

20 out of 50 doesn’t look so bad. [I had to stop counting at the 5th page because I was using a free shodan account.] So the statistics which say 40% was kind of surprising. Does it actually imply that almost 40% of the MongoDB instances out there allow unauthenticated access? Not necessarily. Statistically speaking, the number 50 isn’t even sufficient to be called a ‘representative sample’ when you consider a tool with a significantly large user base.

So I decided to dig a little deeper. What if I try to dig into the result for each country?

Shodan — Country-wise results for MongoDB servers

And these were the results.

106/300 ! Approximately 35%. That’s a shocking figure I think.

Collateral discoveries

There were two collateral discoveries made while I explored these.

I wasn’t the only one

Quite a while after browsing through so many shodan result pages, I realized that I wasn’t the only one who figured this out. And guess what, they already started making money out of it too.

A record left by the attacker in one of the compromised MongoDB instance.

More than half of the vulnerable instances discovered were already compromised by attackers.

AADHAAR [UIDAI] was a bad idea when the govt. agencies themselves have no clue how to protect personal information

One of the servers apparently owned by a Central Government entity was identified to have the same vulnerability.

Compromised server most likely owned by a central ministry.

The ‘test’ database had close to 5 lakh records of personal information including, but not limited to;

Aadhaar No: PAN Card No: Bank Account No: Username/Password Transaction Details/ Salary Details Address Date of Birth

Admin credentials- password hash

Account number and bank details in one of the records.

A record revealing multiple personal information.

In short, every single data needed by an identity thief to impersonate someone! To top it all, this server was already compromised by attackers too.

A record left by the hackers

I reported this to the ministry by mid April and didn’t receive any response. The issue seem to be fixed now as they enabled authentication for MongoDB and hence I am responsibly disclosing the issue even though there was no acknowledgement from their side ;)

The Solution

MongoDB users and admins can follow this guideline to secure their instances.

MongoDB Security Checklist

Update

The government entity mentioned in the article is Coal Ministry Provident Fund Organization. The server mentioned was found to host a test instance of CMPFO e Services on port 3000.