Insecure MongoDB databases expose Russian backdoor access

A security researcher discovered more insecure MongoDB databases online. And, this time, the exposures reportedly revealed backdoor-access accounts controlled by the Russian government.

Victor Gevers, former chairman of internet policy organization GDI Foundation, discovered more than 2,000 exposed MongoDB databases online that belonged to foreign and local enterprises operating in Russia, according to a report from ZDNet.

Gevers discovered the account "[email protected]" in the databases, which would give the Kremlin officials remote access to the data. He noted via Twitter that the Russian government requires remote access into the networks of businesses that operate in the country.  

However, these insecure MongoDB databases were already publicly accessible and did not need a backdoor account for government officials -- or anyone -- to access them.

Gevers told ZDNet that all of the databases in his research were deployed with default settings, which granted CRUD (create, read, update and delete) access to anyone who found them on the internet. No password protections or authentication requirements were found on these databases.  

MongoDB, however, pushed back against Gevers' claim that MongoDB databases are insecure by default. When asked which products and versions had default security settings, the database company issued the following statement to SearchSecurity:

Our most popular downloaded installers have enabled default security since version 2.6, which was released more than five years ago. MongoDB 3.6 (released in 2017) enabled default security across all builds, which also is the case going forward (such as with our most current offering, MongoDB 4.0). We regularly encourage all users to update to current versions for security improvements like default disabling network access, as well as forcing TLS 1.1+ and enabling SCRAM-SHA-256.

With legacy, free versions of MongoDB -- the question asked here -- users don't always enable the extensive security controls MongoDB encourages and makes available to them. MongoDB continues to proactively reach out to users, providing detailed documentation, such as our online training, security manual and security best practice checklist, on how and why to enable security features in legacy versions. We appreciate members of the community, including security researchers, aiding our efforts to identify any misconfigurations and to widely educate users on why and how they should follow documented security practices.

Gevers' research doesn't note which versions of MongoDB were used by the businesses. He told us via Twitter direct message that the vast majority of instances -- 1,523 out 2,001 total exposed databases -- were pre-version 3.6.

"I think the issue got fixed in v3.6, but that was in December 2017," Gevers wrote. "It [took] some years of pushing and complaining to MongoDB to fix this issue of the lazy administrator."

Misconfigured MongoDB databases have been previously documented by security researchers. For example, Niall Merrigan, a security researcher and consultant at Capgemini, reported a spike in cyberattacks in 2017 on MongoDB databases that were publicly exposed on the internet. Threat actors were able to access the databases, which had no password or authentication requirements. And rather than encrypt the data with ransomware, they simply used CRUD access to copy and delete the data and demand ransom payments.

Gevers said via Twitter that he first discovered an exposed MongoDB database for Stoloto, the Russian national lottery, in 2015. Despite attempts to report the issue through responsible vulnerability disclosure, he said, Stoloto didn't address the database exposure until just recently.

Responsible disclosure #4155 took 3 years, 5 months and 15 days to fix the after effect of the leaked credentials. Some breaches don't have to be big in size (as in the number of records which are exposed) to have a significant impact which can take years to fix. [1/2] https://t.co/2DoUjra8X5

— Victor Gevers (@0xDUDE) January 27, 2019

Gevers said on Twitter that many of the organizations he contacted over a three-plus-year span regarding their exposed databases either never responded or acted upon his reports -- even when the organization in question was Ukraine's Ministry of Internal Affairs. Gevers said changing the password system on that database "was too much effort" for Ukraine's government.