Don't Pay the MongoDB Ransom

Last week when I wrote on IT Pro about the ransomware attacks on MongoDB, I thought this was news that would soon blow over. With about every tech site on the planet reporting the story, I thought by now everyone would have checked their MongoDB instances, reconfigured as necessary and moved on. After all, the attack wasn't being brought about by some obscure coding error that bad guys had discovered and were now exploiting to their advantage, but by simple configuration errors that admins worth their salt would never allow happen in the first place.

How simple? As simple as making sure the DB isn't publicly accessible via the Internet. Or as simple as making sure that the default password can't be used to gain read/write privileges.

Of course, the folks at MongoDB share some blame for shipping their product with unsecure default settings, but they fixed that back in 2015, and several agencies have been working overtime since to get the word out -- even going so far as notifying vulnerable database owners directly. But it's not all the fault of MongoDB and admins. It appears that AWS has been supplying its users with older versions, making it no surprise that Mongo on AWS is prime target number one for these breaches.

I'm not even sure that "breach" is a good word to describe these intrusions. Is it a breach when a door is found standing wide open? In this case, all the attackers have to do is run a quick search on the IoT search site Shodan to find URLs to these wide open doors. After that, it's just wipe the DB's data, replace it with a ransom note, and sit back and wait for the bitcoins to roll in.

Except they're not rolling in -- no matter how many organizations are panicking and paying the ransom -- and that's where things might seem comical if it weren't for the valuable data being lost. It's sort of the case of the Keystone Hackers.

As anyone who's watched more than a couple of episodes of "Law & Order" can tell you, paying a ransom is seldom a good idea -- because it rewards bad behavior and there's no guarantee that the stolen data (or loved one) will be returned unharmed. In this case there's another reason -- it's downright futile.

The hack is so easy to pull off that the market has become glutted with black hats chasing the same dime...er, bitcoin. Cracker/hackers are discovering that the sites they're after have already been hit and -- being resourceful capitalists -- are replacing the ransom note that's already there with their own. By the time the database owner discovers the breach, the ransom note might be at generation four -- meaning paying up will do absolutely no good, because the person who left the note can't possibly return your data even if he's inclined to do so, because he isn't the guy who stole it.

In other words, if you fall victim to this hack you can forget about getting your data back. About the best you can hope for is that you have a recent backup.

Last week when I wrote about this, the number of compromised sites was at 2,000. Again, I didn't expect it to go up much from there, as the word had gone viral. By Friday, however, Sean Michael Kerner was reporting on eWeek that the number had risen to over 10,000. Wednesday, Fahmida Y. Rashid reported on InfoWorld that the number now stands at somewhere between 29,000 and 32,000, "depending on whom you ask."

Do yourself a favor. If you're running any instances of MongoDB, stop what you're doing and make sure that you're running the latest and greatest with the correct default settings. If not, upgrade to the current version and check MongoDB's page for best security practices to make sure that you're good-to-go as far as basic security is concerned. There are a lot of people looking to nuke your data right now.