You have to admit that the bad actors are very good at leveraging a vulnerability into a lucrative opportunity. The latest example comes from MongoDB, a popular, open source database commonly deployed for big data applications on the Internet.
The default installation for older versions of MongoDB did not force basic security controls such as a password for the administration account. Installed behind firewalls in a “traditional” data center configuration, the default installation is bad practice, but not necessarily a significant risk. Layers of protection mitigate the missing controls.
Unfortunately, many cloud hosting providers allow easy installation of MongoDB making it directly accessible from the Internet by default without a simple way to setup the security controls. Strip away layered security controls and do not force basic configuration security and you have a recipe for disaster.
“The most open and vulnerable MongoDBs can be found on the AWS platform because this is the most favorite place for organizations who want to work in a devops way,” Victor Gevers told Bleeping Computer. “About 78 percent of all these hosts were running known vulnerable versions.”
In December 2016, one bad actor started compromising vulnerable MongoDB databases. Contents were downloaded and replaced by a ransom note demanding payment in exchange for a return of the missing data. By January, many hacking groups were involved and over 20,000 vulnerable MongoDB installations were compromised. With that many groups in competition, databases were compromised multiple times and ransom notes from one group were replaced by ransom notes from another group. It was unclear for victims who had their missing data and who the ransom should be paid to. Victims paying the ransom were unlikely to get their data back.
After this flurry of activity in the first few months of 2016, the number of MongoDB attacks quieted over the Summer. Perhaps the victims had learned their lessons? Maybe they accepted their fate and couldn’t be ransomed again? Maybe the bad actors were taking the Summer off to spend their ill gotten gains? What we do know is that there are still thousands of vulnerable databases. Attacks against MongoDB databases picked up again in September — at a much faster pace. “[it] took attackers from the first wave of MongoDB attacks nearly a month to rack up 45,000 ransomed DBs. The Cru3lty group managed [22,000] only last week.”
Obviously, the bad actors have figured out how to script the attacks, but how do they find the targets? The same way most vulnerable systems are found on the Internet, SHODAN. The self-described “search engine for Internet-connected devices” is an easy place to find Internet of Things (IoT) devices. A great place to identify vulnerable web cams, refrigerators, industrial control systems (ICS), web apps and databases. If it is connected to the Internet you can find it in SHODAN. Once you know how to identify vulnerable MongoDB installations, add some scripting magic, exploit, ransom and repeat.
“New MongoDB instances which are not indexed by the famous search engine Shodan are not being hit. This means some groups don’t scan themselves but simply use OSINT,” said Victor Gevers, chairman of the GDI Foundation. One of the lead researchers tracking the ongoing exploits.
With all of the media coverage and the number of people affected at the beginning of the year, you might expect that everyone has checked and protected their MongoDB installations. But that is obviously not the case. According to a Google Docs spreadsheet maintained by the researchers, the count of compromised databases is almost 76,000. Obviously, the people installing MongoDB aren’t putting in the effort to secure their installations so the MongoDB team is changing their default installs to be more secure. If you are responsible for an existing MongoDB installation, you should check out the official MongoDB Security Checklist to ensure you are protected.