MongoDB ransom attacks continue to plague administrators

IT shops and developers feeling the pain of trading speed and access for security

erase blackboard wipe
Thinkstock

Earlier this month, Salted Hash reported on a surge in attacks against publicly accessible MongoDB installations.

Since January 3, the day of that first report, the number of victims has climbed from about 200 databases to more than 40,000. In addition to MongoDB, those responsible for the attacks have started targeting Elasticsearch and CouchDB.

No matter the platform being targeted, the message to the victim is the same; send a small Bitcoin payment to the listed address, or forever lose access to your files.

The problem is, some of the more recent attacks show evidence the database was erased. So even if the ransom is paid, the data is lost for good.

The researchers tracking these attacks are aware of at least four individuals who delete the databases entirely after running a list command. Once deleted, they’ll leave the ransom note and logoff the system. So far, these individuals have used more than a dozen Bitcoin wallet addresses, and nine different email accounts.

The tracking document is available on Google Docs.

Based on the most recent figures, ten organizations paid the ransom in order to restore their databases, but not a single one has had their data returned. Only one of those victims had backups to use when the ransom payment failed.

But MongoDB was just the start.

Soon, criminals started going after other development platforms, such as Elasticsearch - a Java-based search engine that's popular in enterprise environments. Then they moved on to public facing Hadoop and CouchDB deployments.

Researchers at Rapid7 Labs have been following these attacks and used Project Sonar to look at the current situation.

"The core reason why attackers are targeting devops-ish technologies is that most of these servers have a default configurations which have tended to be wide open (i.e. they listen on all IP addresses and have no authentication) to facilitate easy experimentation [and] exploration," a report from Rapid7 explains.

"Said configuration means you can give a new technology a test on your local workstation to see if you like the features or API but it also means that — if you’re not careful — you’ll be exposing real data to the world if you deploy them the same way on the internet."

The attacks targeting MongoDB and the others are automated, and there have been cases where more than one attacker has hit the same exposed server.

Stats for exposed and attacked databases Rapid7

Using Project Sonar, Rapid7 discovered 55,895 MongoDB installs in the public. Of those, 50-percent were compromised. When it comes to the exposed Elasticsearch servers (18,221), 42-percent had been hijacked and held for ransom. Finally, for CouchDB, Rapid7 discovered 4,490 systems and 90-percent of them had been compromised.

The numbers align with other points of discussion and comments online, but the report does state that independent results will very. This is due to the number of organizations that block Project Sonar scans outright, or those who have asked that Rapid7 not scan their subnets.

Hosting and version tracking for databases held for ransom Rapid7

The Project Sonar data shows that Amazon is the top host for most of the targeted platforms, followed by Softlayer, EGIHosting, and Digital Ocean.

Looking at the data for MongoDB, most of the attacks have been against installations that were still receiving support. However, MongoDB 2.6 and 2.4 (both end-of-life) were both the second and third most commonly attacked respectively.

The Rapid7 report suggests starting with proper configuration as a way to deal with these most recent attacks, as well as the others soon to follow. In addition, it’s also important to make sure the software is updated regularly and that access to the server is limited.

"You should also configure your monitoring services and vulnerability management program to identify and alert if your internet-facing systems are exposing an insecure configuration. Even the best shops make deployment mistakes on occasion,” the report’s authors conclude.

The links below contain advice and other important security tips.

SUBSCRIBE! Get the best of CSO delivered to your email inbox.