Insecure MongoDB configuration leads to boom in ransom attacks

Cybercriminals have found weaknesses in many MongoDB configurations that have opened the door to tens of thousands of ransom attacks.

Niall Merrigan, security researcher and Microsoft developer based in Norway, has been tracking the MongoDB ransom incidents, and in one day, he saw the number of attacks more than double from 12,000 to 27,633. Unlike ransomware, in which data is encrypted, attackers have been accessing databases, copying files, deleting everything and leaving a ransom note promising the return of the data for a fee.

"The issue is here that people have set these databases up and [started] building applications quickly without due security considerations," Merrigan told SearchSecurity. "In a lot of cases, they just didn't know they had to set up authentication, which is not enabled out of the box by default."

Victor Gevers, an independent security researcher based in the Netherlands, told SearchSecurity poor authentication policies in MongoDB configuration was the main weakness allowing attackers to access databases.

"They are all misconfigured because they allow [anyone] to access the database with full admin rights without authentication like you would expect from a NoSQL database," Gevers said via email. "So, it's the responsibility of the owners who did not configure the data correctly for using internet-facing [systems], and this mistake becomes clear the moment you kick off a decent vulnerability scanner. It's not rocket science to detect these misconfigurations."

John Bambenek, threat systems manager at Fidelis Cybersecurity, based in Bethesda, Md., said the main problem is "people are putting up internet-facing services with no real attempt to secure and maintain them." 

"All too often, development efforts focus on doing things quickly, rather than making sure things aren't accessible to the world without authentication," Bambenek told SearchSecurity. "It appears, in this case, many of these MongoDB databases were installed using an installer that did not set a password on the admin account, but made the database accessible to the world."

Vahagn Vardanyan, senior business applications security researcher at ERPScan, based in Palo Alto, Calif., hackers did not use any zero-day vulnerabilities in these attacks.

"By default, after the installation, MongoDB doesn't require authentication to connect to the database," Vardanyan told SearchSecurity. "Database administrators don't configure it securely, so hackers use this fact to make hay."

Gevers confirmed there are known vulnerabilities in MongoDB, but there was no indication of any vulnerabilities used in the attacks investigated.

"All the attacks do pretty much the same. They try to copy the database with MongoDB, and then delete the database, create a new one with one record holding the ransom note and wipe the journal before they exit," Gevers said via email. "Because the log stays intact, we can extract the same attack pattern and IPs from where the attack is launched. There is no other evidence showing that [attackers] have placed a persistent backdoor -- by creating an admin user -- or a shell."

The number of MongoDB installations at risk was hard to pin down, according to Merrigan and Gevers. Using Shodan.io, Merrigan said there were close to 52,000 servers accessible to the internet that were not enabled for authentication. Gevers put the number at around 48,000 when searching Shodan, but found it could be as high as 99,000 bad MongoDB configurations, according to data from ZoomEye.

Aaron Shelmire, principal threat researcher at threat intelligence platforms provider Anomali Inc., based in Redwood City, Calif., said it was far too common for an organization to have a bad MongoDB configuration.

"Every couple of years, a new technology stack arises, and it seems like the industry spends a good bit of time relearning old lessons. It's amazing how many incidents arise because of simple security oversight," Shelmire told SearchSecurity. "The best method to keep these items secure is to limit access to these services to your hosts behind your corporation's VPN. Configuring regularly scheduled backups of these data stores can limit the impact of a compromised and ransomed system."

Merrigan said backups can help restore "business continuity," but suggested better authentication policies for MongoDB configuration.

"Use the least-principle concept. Don't try and lock it down; it is much easier to only open up as needed," Merrigan said. "Look at the MongoDB guides for hardening systems, especially internet-facing ones. And assume everyone is out to get your system if you leave it out on the internet."