'Meow' Attack Has Now Wiped Nearly 4,000 Databases (arstechnica.com) 54
On Thursday long-time Slashdot reader PuceBaboon wrote: Ars Technica is reporting a new attack on unprotected databases which, to date, has deleted all content from over 1,000 ElasticSearch and MongoDB databases across the 'net, leaving the calling-card "meow" in its place.
Most people are likely to find this a lot less amusing than a kitty video, so if you have a database instance on a cloud machine, now would be a good time to verify that it is password protected by something other than the default, install password...
From the article: The attack first came to the attention of researcher Bob Diachenko on Tuesday, when he discovered a database that stored user details of the UFO VPN had been destroyed. UFO VPN had already been in the news that day because the world-readable database exposed a wealth of sensitive user information... Besides amounting to a serious privacy breach, the database was at odds with the Hong Kong-based UFO's promise to keep no logs. The VPN provider responded by moving the database to a different location but once again failed to secure it properly. Shortly after, the Meow attack wiped it out.
"Attacks have continued and are getting closer to 4,000," reports Bleeping Computer. "A new search on Saturday using Shodan shows that more than 3,800 databases have entry names matching a 'meow' attack. More than 97% of them are Elastic and MongoDB."
Most people are likely to find this a lot less amusing than a kitty video, so if you have a database instance on a cloud machine, now would be a good time to verify that it is password protected by something other than the default, install password...
From the article: The attack first came to the attention of researcher Bob Diachenko on Tuesday, when he discovered a database that stored user details of the UFO VPN had been destroyed. UFO VPN had already been in the news that day because the world-readable database exposed a wealth of sensitive user information... Besides amounting to a serious privacy breach, the database was at odds with the Hong Kong-based UFO's promise to keep no logs. The VPN provider responded by moving the database to a different location but once again failed to secure it properly. Shortly after, the Meow attack wiped it out.
"Attacks have continued and are getting closer to 4,000," reports Bleeping Computer. "A new search on Saturday using Shodan shows that more than 3,800 databases have entry names matching a 'meow' attack. More than 97% of them are Elastic and MongoDB."
Too late (Score:3)
The cat is out of the bag.
Meow!
Re: (Score:2)
SQL Slammer is remembered.
So this only affects unsecured databases? (Score:5, Insightful)
Re: (Score:2, Insightful)
My thoughts as well.
If the data is gone, then it's not going to be part of another data breach!
Re: (Score:2)
Do we know that? So it's not a download and wipe?
Re: (Score:2)
May be?
Someone decided to do a public service on a large scale. Governments should really offer bounties for this kind of thing.
Re:So this only affects unsecured databases? (Score:4, Informative)
Especially when you consider that, until relatively recently, Elasticsearch security (the "X Pack") was a non-free add-on.
Re: (Score:1)
Re: (Score:2)
It may be doing more good than harm.
Pretty much. At least this is much better than privacy-relevant data leaking.
Re: (Score:2)
I agree, it's much better to have the database wiped than stolen
Re: So this only affects unsecured databases? (Score:3)
Came here to say this. Teach idiots a low-cost lesson, while deleting data that might be sensitive.
Good kitty...
Re: (Score:2)
Re: (Score:3)
Details on how ./ avoided this hack (Score:3)
Meow
Re: (Score:2)
Re: (Score:3)
Don't expose the database server to the internet or even intranet. Run it on a separate segment.
No thanks required (Score:5, Funny)
UFO VPN ... the world-readable database exposed a wealth of sensitive user information. ... UFO's promise to keep no logs ...Shortly after, the Meow attack wiped it out.
Thus fixing the problem!
Usually cats drop things off tables (Score:3, Funny)
F**kers like this (Score:2)
Re: (Score:3)
The vigilante vandals, or the incompetent administrators?
Re: (Score:3)
Re: (Score:1)
it's always those admins fault and never management either right?
Re: (Score:2)
I'm hard pressed to think of a way management could possibly be responsible for leaving a database unsecured on the internet with default password, unless they themselves created it which seems unlikely.
I'd agree they are indirectly responsible due to shoddy hiring practices though.
Re: (Score:1)
Or the ones wanting those admins to hoard all that data in the first place?
Re: (Score:2)
Or the ones wanting those admins to hoard all that data in the first place?
Smart admins will just turn off logging and insert one record that reads "meow". When management or law enforcement comes around asking for data, they just respond "Oh noes! It looks like we've been hacked!"
Re: (Score:1)
Both
Re: (Score:1)
>> [kneecapping]
> The vigilante vandals, or the incompetent administrators?
False dichotomy.
Re: (Score:2)
Re: (Score:2)
need to be knee-capped.
Why? I'd rather the hackers delete my data that the company left in the open, than some other hackers collect it.
Re: (Score:2)
Why? I'd rather the hackers delete my data that the company left in the open, than some other hackers collect it.
That's a good point. It might even convince the DB owner to set a real password.
With that said, I gotta admit I'm okay with the kneecapping.
Re: F**kers like this (Score:2)
You're assuming they didn't slurp all the data before they overwroye it.
Re: (Score:2)
You're assuming they didn't slurp all the data before they overwroye it.
Even if they did, I'd still rather only one group get it than everyone.
Re: (Score:3)
Many of these are probably virtual servers. You set up whatever you want yourself.
Why Mongo *still* defaults to sharing a database on the Internet with no security is a good question.
Re: (Score:2, Flamebait)
"This is not rocket science."
The average DB admin is as dumb as a rock.
Now remember, that 50% of them are statistically still dumber.
Re: (Score:1)
Most databases are not setup by database administrators is the real problem. They're setup by programmers or sysadmins who really don't have much clue about the software they're being tasked to setup(through no fault of their own, its not their speciality).
You wouldn't let your plumber do your electrical work(or you shouldn't, the horrors of the plumbtrician...), don't let your software developers do your database administration.
If you have anything facing the Internet (Score:2)
It would be a good idea to " verify that it is password protected by something other than the default, install password"
That includes hardware as well as software.
Re: (Score:2)
Unless you wanted to "shred" a bunch of documents and make it look like someone else did it. Why no FBI agent, I didn't delete the database. Meow.
Re: (Score:2)
Re: (Score:2)
The creators of SSH have security as their top priority, whereas the creators of databases do not.
Duh wow you mean I can't (Score:2)
No, no, no (Score:2)
"... now would be a good time to verify that it is password protected by something other than the default, install password..."
No.
A "good time" to verify that it is password protected by something other than the default is when you fucking install it.
If this is the competence level they operate at then they have no business doing anything with databases.
Cloud computing (Score:3)
"unsecured"? (Score:1)
What exactly is an unsecured database? All I've ever used is MySQL and Oracle and creating passwords for accounts/databases (and requiring credentials for transacting with them) is nonoptional. What database engine doesn't use credentials, and why?
Re: (Score:2)
After a fashion, the database is to the system it is running on like a server (virtual or not) is to the firewall connecting it to the network.
To be secure, your database needs a password.
But if someone on the system can simply open and modify (database) files, then password or not, they have avoided your database system's security.
So your system ( and/or network) needs a password too.
And given flaws in systems, you need other security measure such as routing tables that only allow access from particular ad
Re: "unsecured"? (Score:3)
Elasticsearch, until very recently, had no support for security at all. It is designed to be run in a private network or behind an auth proxy. Depending on where you get the source code, it will usually default to only listen on localhost, but since it's cluster software, any real use case is going to open that up.
Re: (Score:2)
I think you can force MySQL to run the root user without a password. In ye olden days, it was just an option in my.cnf, as I recall, but now you really have to go out of your way. Early on in teaching myself MySQL I was running a Windows port on Windows 98 of all things, and as I recall I was running without password. Security wasn't a big consideration, because I had dial up Internet, and I was just running the server on localhost.
Re: (Score:2)
Re: (Score:2)
from what I am reading its mostly no name garbage that's trying to sell you a service you do not need
Re: (Score:2)
No, you are wrong about that. Some installers(the deb packages on Debian and Debian-derived distributions) force you to create a root password on installation, but others ( the rpm packages on Red Hat and Red Hat-derived distributions) don't.
Nothing in the MySQL database itself requires a root password.
It's a public service. Digital Robin Hood (Score:2)
Any database that's publicly exposed needs to be wiped ASAP. Those incompetent motherf$%e$rs don't deserve to have our data, and wiping it before the Chinese or Russian or Iranian state backed a-holes get it is a public service.
Thank you Robin Meow!