Hacking Groups Attack More than 20 Thousand MongoDB Databases

A new barrage of ransom attacks targeted MongoDB databases, affecting tens of thousands of servers. Multiple hacking groups are reportedly behind the attacks, with one of them already compromising 22,000 servers.

The attackers targeted publicly accessible databases running with default settings, deleting the data and replacing it with a ransom note that reads:

"We have your data. Your database is backed up to our servers. If you want to restore it, then send 0.15 BTC [$650] and text me to email, just send your IP-address and payment info. Messages without payment info will be ignored.”

Late last year, MongoDB databases were also subjected to attacks, affecting at least 40,000.

It is not surprising that such databases are being targeted on the internet. The attacks on MongoDB aren’t isolated incidents; ElasticSearch, Hadoop, and other sources of publicly accessible data were also hit by similar attacks this year. There's profit in going after data; it has value in the underground, and ransomware attacks have also proven how victims are willing to pay.

According to a Google Docs spreadsheet that GDI Foundation chairman Victor Gevers and fellow researcher Dylan Katz are updating, payments of over 24 BTC (US$110,100) had been received by the hackers, with 275 listed transactions.

Mitigation

To prevent attacks against MongoDB, users should follow what’s written on the program’s Security Checklist. The list discusses the proper way of enforcing authentication, enabling access control, and limiting network exposure. Using the most popular installer for MongoDB (RPM) should also be considered as it limits network access to local host by default.

Users should rethink if they really want to deploy a publicly accessible data source that is directly connected to the internet. If it is the right design choice, understanding the technology and services in their solution stack is the next step to a strong defense. Limiting the privileges of front-end identities making requests should be considered, as well as making sure that each session uses a unique ID instead of a having single ID for the entire application.

After determining what and where to deploy applications, basic testing should be done to ensure that they're configured properly. As part of regular deployment testing, basic tests should be run to see if services are accessible from appropriate places.