What's worse than paying an extortion bot that auto-pwned your database? Publicly exposed PostgreSQL and MySQL databases with weak passwords are being autonomously wiped out by a malicious extortion bot – one that marks who pays up and who is not getting their data back. Origin unknown, the bot is routinely breaching poorly protected databases within hours of exposure to the internet, according to …
Because if companies who pay ransoms find they've been ripped off, then they'll perhaps slowly start to learn that (a) they need better security, (b) they shouldn't have data readily accessible unless it really needs to be readily accessible, and (c) paying a ransom encourages the criminals whilst not guaranteeing anything back for the company.
Considering that they already know the Bitcoin wallet the ransom funds are (eventually) transferred to, why don't they just confiscate that? They already know that it is involved in [highly] illegal activity.
Also, more a lesson on keeping backups, isn't it?
You can't just confiscate a wallet. You know the identifier that it's going to, but the only thing you can really do without the private key is to shout loudly that whoever has this is evil and you shouldn't exchange with them. If people listen to you, then they'll be less able to exchange their funds for money they can actually use. If people don't, you're mostly out of luck.
hiring some private investigators and a hitman
To, what, find out who currently controls a particular Bitcoin wallet? (Of course, if they take your money, report they've found the criminal mastermind behind this intricate plot,1 and ask for more money to bring him to justice / have him whacked, how would you verify their claims anyway?)
Honestly, it's like every story about ransomware brings out the dumbest responses.
1Yes, that's sarcasm. Though apparently it's too intricate for some.
Yes I hope more ransomware crims fail to deliver on their promises of returning data unharmed. That makes me wish there was some group of gray hat hackers who flooded the market with ransomware that destroyed data and NEVER anything back after payment. If everyone believed there was only a low single digit chance of getting back their data, no one would pay ransom anymore and the whole "industry" would die.
Some gray hat hackers taking matters into their own hands may be the only way to fix the problem, if the will doesn't exist to actually fix the problem by imposing a total ban on all ransom payments or offering of "ransomware insurance".
It's a bot. It doesn't care if no one pays ransoms. It'll keep running until all copies of it are shut down.
The "if no one pays ransoms, ransomware will go away" idea is impossibly naive, and this article shows why. Yet commentators immediately start spouting it again.
I wouldn't claim that nobody paying ransoms would completely stop ransomware, but you act like the bot is independently trying to encrypt systems because it finds it fun. It's only there because someone wrote it and is prepared to operate it. If they are not able to make money, they don't need to operate it anymore unless they have another goal. Attacks intended to destroy something masquerading as ransomware would be unaffected, but people who are in it for the money would start to find other ways to get money with the willingness and ability to write malicious software.
If I follow this correctly then the main reason this is happening is - drum-roll - cloud.
I can more or less understand the need to export a database connection to support remote working if the users have the DB client application local to them. In that case it ought to be wrapped up in a VPN and have proper security. Even then, it would be better to put the application on the server so the remote link is only handling the UI.
This again? The main reason this is happening is - drum-roll - admins leaving stuff with open ports to the internet. People do that on networks where they control the hardware all the time. In fact, they do it more often there because the cloud providers usually have a default configuration that includes firewall rules and, when they can, doesn't assign a public IP address because those are expensive. You can really easily open it back up in the cloud, but you can also really easily open it up on your own network, and I'm sure we've both seen people who have done it and need to be corrected. Blaming cloud providers for admins not understanding the basics of security (don't have an internet-facing database unless you really have to, if you're not sure you don't really have to, if someone else thinks you don't need it then you probably don't need it, and the password should never be the default especially when it's internet-facing) is not helpful. Not only is it not helpful because it lets the ones who caused this off the hook, but because it makes it look like you're biased against and don't understand cloud hosting, so when you have real complaints about cloud, people won't believe them.
It's not like there's just "a password" for a database.
There can be hundreds of them. They can be for doing different things.
You can have users who can only look at the data, users who can modify some tables but not others, and if you like you can set things up so that nobody except the admin can drop anything.
You can restrict access to certain hosts, IP addresses or whatever.
In this article I seem to be reading examples of cluelessness and/or carelessness and/or laziness taken to extremes.
It's inexcusable.
Even I can't drop a table in my own databases if I'm logged in as me. To do that I have to log in as the database administrator, which can't be done from outside the LAN - and if you did get a toehold in the LAN because I somehow screwed up a firewall, good luck guessing the DBA's password.
It's perfectly routine to set things up that way.
The database purveyors would do their more irresponsible users a great favour by helping to make careful permission setups the default.
They've provided all the tools a good administrator needs to have a really strong permissions setup, including lots of integrations with other authentication systems. At some point, the administrators need to start to use them and the writers of the engines can do little to change it. The only change I see is requiring the user to enter a password at the start, rather than having a typical default, although many packages for the database engines already do that.
Walking people through the process of creating limited roles will probably not work because anyone who doesn't understand to do it on their own will probably just create one user and grant everything to them, then exit the setup. I might even do that, because even though I really like having particularly limited access roles, I tend to set them up when the program that's going to use them is created rather than at the time of database creation. I'm not sure there are a lot of options that have the program prevent stupid administrators from doing stupid things.
""It's not surprising to see many open database services in the public cloud," the researchers said. "If you run your database in say DigitalOcean or even AWS, then these cloud providers don't always make it easy to access your database from your desktop, or even a workload running in a different region or provider. You may have no other option than to open it from anywhere. And so, while bad practice, it's not all that surprising that there are that many open databases."
That assertion is not a little bit wrong, it's dead wrong.
I'm no AWS freak, but setting up a lambda to update a security group or IP set to permit access from the IP address of the caller of some sort of SAML'ed or OAUTH'ed user is NOT a major project. Yes, there are some "quirks" to work through, but it is NOT hard.
It does require some dedication to the basics, however.
I suspect you lost a lot of developers at "some dedication".
Just today someone on my team had to explain POSIX file permissions to a customer, running one of our (non-trivial) software packages on Linux. We see this all the time: Customers don't understand even the OS they're using. Their developers don't either. If there are system administrators, they're nowhere to be found. And DBAs? Not for those "create a web app in a day!" types; they'll just follow some tutorial to get a LAMP stack or the like running, and cobble together a wildly-insecure and unmaintainable monstrosity.
(Not saying the LAMP stack is necessarily the problem, though I do think PHP is god-awful. The problem is telling people how to shoot themselves in the foot with it.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
