Hackers blackmailed 23,000 MongoDB databases, leaking data without paying

Original title: "Hackers Blackmail 23,000 MongoDB databases, Leak Data without Paying"

Originally written by Wan Jia, InfoQ

According to ZDNet, 22,900 MongoDB databases exposed online have been blackmailed by hackers. The hacker reportedly used an automated script to scan the misconfigured MongoDB database, delete the contents of the database, and then leave a ransom message asking users to pay 0.015 bitcoins (the equivalent of $140).

The attacker gave the database owner two days to pay the ransom. If no ransom is paid, the attacker also has "Plan B" : threatening the victim with their data and contacting the victim's local GDPR regulator to report the breach.

That would expose victims to pressure from GDPR regulators even if they do not pay ransoms.

It is understood that the 22,900 extorted MongoDB databases accounted for 47% of all exposed MongoDB databases on the Internet.

The blackmail messages planted by the attackers were first discovered in April 2020. Victor Gevers is a cyber-security researcher at the GDI Foundation, which partly reports on servers exposed online to companies. He said the initial attack did not involve deleting data from the database.

The attacker continues to connect to the same database, leaving a ransom record, and returns a few days later to leave another copy of the ransom record. Gevers says the attackers seem to realize they've made a mistake in the script. Not long after, the attackers fixed their scripts and are now actually cleaning up the MongoDB database.

Although some of these databases look like test cases, Gevers says some production systems are also under attack.

MongoDB blackmail event

The hackers broke into a user's MongoDB database, erased the data and left a message demanding thousands of dollars in bitcoin as ransom. The attack is known as the MongDB extortion incident.

In fact, MongoDB ransomware occurred several times a few years ago.

MongoDB was blackmailed by hackers in late December 2016, culminating in January 2017. The attacker took advantage of MongoDB with faulty configuration to carry out extortion behavior. The hacker organization calling itself Harak1r1 collected the data from the MongoDB database disclosed on the network and removed the data from the MongoDB server. The first 200 MongoDB instances were purged illegally, and within days, the number of infected MongoDB instances had grown to more than 10,000. The attacker demanded 0.2 bitcoins (then worth about $184) for the data, and as the number of infected databases grew, the attacker increased the ransom to one bitcoin (worth about $906). The event is called the MongoDB Apocalypse.

The attacks made hackers realize that they could make more money by wiping out MongoDB servers and leaving ransomware to trick server owners eager to get their files back.

In September 2017, the MongoDB database was subjected to another extortion attack by hackers, with three hacker gangs hijacking more than 26,000 servers. Compared to "MongoDB Apocalypse", the number of attackers is down, but the number of destructiveness (victims) per attack is up.

In 2017, Davi Ottenheimer, MongoDB's senior director of product security, condemned the practice, noting that one of the reasons it happened was that the database owner had failed to set a password for the database and had exposed servers that were not configured with a firewall.

Almost three years later, little has changed.

At the beginning of 2017, there were 60,000 MongoDB servers exposed online, and now there are 48,000 more exposed online, most of them without authentication enabled.

The reasons behind the security problem

Why is MongoDB so vulnerable?

In this article, the author points out that the biggest security problem with MongoDB comes from MongoDB's default configuration. Under the default deployment, MongoDB can log in without authentication. Criminals can directly access MongoDB through tools as long as they find MongoDB address and port on the Internet, and have all privileges of MongoDB, so as to carry out any operation. The reason for this design lies in:

By default, MongoDB is customized to run on virtual machines (low provisioning machines) by the simplest deployment method to maximize the running speed, without fully considering the security of MongoDB.
MongoDB official documents, such as documents and guidelines for authentication, transmission encryption, and network configuration, are not standard, which may easily mislead MongoDB administrators.
Some MongoDB environments are built for a single project or test environment, and the builders do not care about MongoDB security issues.

As for MongoDB extortion event, Tang Jianfa, founder of MongoDB Chinese community and chief architect of MongoDB Official Greater China region, summarized in "No Technology is Perfect" : Complete Record of MongoDB's ten Years of Development:

MongoDB, in order to facilitate programmers to develop applications quickly to the greatest extent, the default mode does not need to set user name and password to log in. As a result, many careless programmers, especially startups, often fail to enable authentication when the system goes live. Let's say you buy a house and you don't use the door lock.

In my opinion, security is critical for anyone using MongoDB. Once neglected, MongoDB is exposed to online extortion is trivial, and if the data is deleted, the losses are unlimited.

Text link:https://mp.weixin.qq.com

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia