Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New ‘Meow’ attack has deleted almost 4k unsecured databases

bleepingcomputer.com

Post reply on HN
Print view View original

461–470 of 544 posts

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#461

Post by LdSGSgvupDV »

nisa wrote: post #60
rectang wrote: post #27

If the databases in question (Elastic, MongoDB, others) make it too easy to set up unsecured access, possibly because they default to an unsecured state on installation, then some good may come of this: The reputation hit to the database vendors should encourage them to mend their ways. If that happens, then the attack can arguably be justified despite the damage — consider all the future database installations which…

It's also easy to get bitten by Docker. You can secure your server with iptables/ufw only to discover that docker happily punches through your firewall and you need to filter on the DOCKER-USER chain - and even that was broken: https://unrouted.io/2017/08/15/docker-firewall/ https://github.com/docker/for-linux/issues/690

I have encountered this firewall problem (deploy service locally by docker). In that time, I managed to manually set iptable to solve the problem.

But, after some search, I found that simply setting "network_mode" to "host" could solve my problem. So, I ended up not to deal with iptable.

If someone want to deploy some self-hosted service, I would suggest using traefik v2. Outfit docker quite well especially with letsencrypt.

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#462

Post by mushi »

tgsovlerkhgsel wrote: post #420
moooo99 wrote: post #343

Earlier quoted context omitted.

> Recommend to setup two subnets in your project. One public and one private. This is very good advice. We recently had a uni project where we had to use a MongoDB database. Somebody just apt-get installed a mongodb onto a DO droplet called it a day. Two days later the only remaining records prompted us to transfer x amount of BTC to a adress that was store in our DB. It just contained dummy data, but it is worrying…

> Somebody just apt-get installed a mongodb onto a DO droplet called it a day. Two days later the only remaining records prompted us to transfer x amount of BTC to a adress that was store in our DB. If the default install does this, then I'd blame the package /distro maintainers. It should definitely at least only listen on localhost by default, with stern warnings what is going to happen if you change that without s…

MongoDB only binds to localhost for at least the last four versions (4+ years). Someone would have had to install a really old version or intentionally configure it to listen to public IP.

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#463

Post by mushi »

bmcahren wrote: post #102
lol768 wrote: post #38

Earlier quoted context omitted.

I've said it on here before, but the way in which Elasticsearch used to lock away critical security functionality (like TLS support and RBAC) behind a paid subscription whilst making just enough functionality available for free such that users could shoot their foot off is disgusting. This only ever changed after Open Distro for Elasticsearch came onto the scene and forced Elastic's hand. I entirely agree the vendors…

This is why we are refactoring our database to be able to migrate to Amazon documentdb from MongoDB. Encryption at rest.... Pay up!

You’re switching from a free database to a paid one because what?

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#464

Post by exadeci »

rectang wrote: post #27

If the databases in question (Elastic, MongoDB, others) make it too easy to set up unsecured access, possibly because they default to an unsecured state on installation, then some good may come of this: The reputation hit to the database vendors should encourage them to mend their ways. If that happens, then the attack can arguably be justified despite the damage — consider all the future database installations which…

Wasn't there a guy that thoroughly tested databases found that MongoDB was awful? I'm pretty sure many of his articles were posted here.

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#465

Post by mushi »

tdeck wrote: post #389
nkrisc wrote: post #318

Earlier quoted context omitted.

Because if it's not destructive they have no reason to pay attention. Change names back and it's business as usual.

IDK, if someone kept changing the table names in my DB every week I'd probably throw a password on it, even if I were really lazy. Most of these people probably didn't realize their DBs were unsecured, and that gets the point across quickly (particularly if the new table names are chosen instructively).

Someone who’s a bit more lazy might just switch their db from default port and assume all is good!

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#466

Post by emilburzo »

achillean wrote: post #347
AznHisoka wrote: post #211

Is there an inexpensive service out there that does “mock” attacks if you give it a bunch of host names and ports? I know it’s something you could create yourself but would be nice to have a third party try to connect to your databases and immediately alert you if it was able to gain access. Would especially be useful if you were tinkering with firewall/security settings and accidentally opened something up.

Shodan Monitor will do it and if you're only keeping track of https://www.shodan.io/store/member ). You just provide an IP/ network/ domain and we'll notify you if anything changes or becomes vulnerable. It's basically Google Alerts but for network ports: https://monitor.shodan.io Disclaimer: I'm the founder of Shodan.

I'm using this and really love it, but it's annoying if you want to use a domain name instead of IPs, because if the DNS records change the old IPs stay in with the new ones.

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#467

Post by dredmorbius »

KMag wrote: post #458
dredmorbius wrote: post #452

Earlier quoted context omitted.

The data may be modified at any time without a trace, rendering it void. Secure your damned database. The fault and responsibility lie with the deploying organisation and tools vendor. Meow is just the messenger.

But if they had used the password changes API to assign random passwords to all accounts, as suggested, then the data couldn't be modified. Am I missing something?

My understanding is that password-secured DBs aren't vulnerable to Meow remediations.

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#468

Post by KMag »

hhjj wrote: post #453
KMag wrote: post #432

Earlier quoted context omitted.

In some cases, I might be tempted to agree with you, but this is blindly being applied by an automated attack. What if some of that deleted data is volunteer-canvassed anonymized survey data of homeless people, and its loss sets back a homeless relief program by months, resulting in several people freezing to death this winter?

Then people should feel bad their negligence did cost lives.

Both the DB admins and the attackers should both feel guilt. However, if the attackers simply assigned randomly-generated passwords to all of the accounts, then no data would be lost and the DB admins would still have their DBs temporarily become inaccessible while they figured out how to force-reset their passwords. If you're going to go for disruption, I think the suggested lockout gives a much better ratio of good being done to potential damage being done.

Re: New ‘Meow’ attack has deleted almost 4k unsecured databases

#469

Post by bigiain »

dredmorbius wrote: post #428
bigiain wrote: post #385

Earlier quoted context omitted.

I have _some_ sympathy for ElasticSearch and Redis, having designed/built their software under the assumption it isn't ever intended to be publicly accessible over the internet. I have a bunch of fairly important personal documents in a filing cabinet with no lock. And I'm perfectly fine with that. I wouldn't keep it in my front yard, because that's obviously stupid, but keeping it inside behind my locked door and up…

If your assumptions are repearedly demonstrated invalid they are wrong. Change them.

Personally, I reckon that applies at least as much (if not more) to the devs installing random software packages onto internet connected and un-firewalled servers - as it does to database developers who document clearly that their software is not intended and is actively unsafe to install on directly internet connected servers...

Cave ne recipiens donum...

Post reply on HN