Hacker News new | past | comments | ask | show | jobs | submit login
New ‘Meow’ attack has deleted almost 4k unsecured databases (bleepingcomputer.com)
841 points by based2 12 days ago | hide | past | favorite | 518 comments

Works great. You can already find questions on Stack Overflow from people getting their database deleted


Edit: The person raising that question is working for Atlassian (Jira), looks like Atlassian got their database deleted lol

This edit is speculation.

> I'm running an elastic search for a personal project on google-cloud and I use as a search index for my application.

He very clearly says it’s a personal project. Trying to learn new topics outside of your direct responsibilities, while employed, is very common in the software industry. Not everyone that works at a company is involved in databases at that company.

And getting a lesson in security for free it seems, it sucks but security is important.

Free? It would have required more effort, but they could have encrypted all the data, and then sent the key to a well-known white-hat security researcher, or someone who could be trusted to administrate important cases (they'd of course be free to ignore it). The encryption could be done on the compromised server with a forEach, so it'd be a single request.

I think some people in this thread want to be a bit too "absolutist" about it. Everyone's servers were exposed to heartbleed, spectre, meltdown, etc so the absolutists would apparently want the whole internet deleted.

Edit: It would be helpful if down-voter could explain (I might learn something).

> and then sent the key to a well-known white-hat security researcher

Would you like it if someone involved you in adjudicating potentially illegal (under CFAA & others) without your consent?

This is clearly not a white hat hacker looking to teach people lessons about security. If it were, they could have furnished a list to the major cloud providers of broken instances and given them time to notify and remediate.

>Everyone's servers were exposed to heartbleed

No just my Webserver/HAProxy. The difference is, don't expose services that are not meant to face the Inet directly.

Production-Type Webservers are, SSH, VPN, HAProxy etc are.

Databases, devel-webservers, NFS, Samba are not!

Sure even the best hardened Service can have vulnerabilities, but that's how life is, better have a door with a key than one without, even when someone is capable to open your door with a Lock-pick.

> don't expose services that are not meant to face the Inet directly

I did not (in the slightest) suggest that people should do this. I was commenting on the "free-ness" of the lesson (read the comment I was replying to). It could have been more "free" with a little more effort. Straight-up deletion wasn't the only option.

>Straight-up deletion wasn't the only option.

No but a good one.

>It could have been more "free" with a little more effort.

Even White-Hats work not for free (for companys). Don't build Cars if you don't know how a break work, don't build IT-Services if you have no the slightest idea how to secure them.

Fair, but I don't think you've added much to the thread here.

Same same ;)

I wonder how many of the deleted databases are just people learning with databases of dummy data?

Nice, now they learn never expose a DB directly to the net additionally...bonus points ;)

Except of course they probably already knew that, they just accepted to risk to their toy database as a trade-off for the convenience of being able to directly access it over the internet.

Have fun to re-setup it again then...

That was edited in afterwards. https://stackoverflow.com/posts/63067062/revisions whilst it very well may be a personal project, it certainly wasn't "very clear".

Maybe he edited it to clarify after strangers on the internet got him in trouble at work having implied that his employer had suffered a data breach?

Yeah, imagine if someone started stalking you on the Internet and making up random assumptions about your employer based on the questions you asked on a question-and-answer site. Oh and wait, they are doing this slanderous gossip under a pseudonym themselves, so you can't even call them out personally!

Stuff like this is what drives away underrepresented groups from engaging on the internet. Maybe everyone who upvoted and participated in the uninformed speculation from 'user5994461 should reconsider.

I expect if the author learns about this exchange he would never ask a question that has even a remote possibility of inviting speculation about levels of his knowledge or practices at a company where he happens to work at the time (in other words, pretty much any question at all) using his name.

That kind of public ridicule and possible resulting flak from management is why more and more developers participate in knowledge exchange by asking questions from under a throwaway pseudonym (much like user5994461), and only answer or edit other questions from accounts that connect to their identity in any way.

Sounds like a good public service. I’d much rather have my data deleted until it’s secured than have it stolen by someone else.

depends on the data. it could be public records

Databases can be public and secure. If a database can be deleted, it is not secure.

It sure was public...

This is not what people mean by open data

>If a database can be deleted, it is not secure

True, but a deleted database is secure again ;)


Oops no welfare for you!

I understand that some people won't learn without encouragement but it's not a good thing for all.

This attack uses public write access, which is how they can delete stuff. I think we can agree that this is not good, and I also think we can agree that a database shouldn't be exposed as-is without an application layer or API on top

Ultimately, companies like MongoDB and Elasticsearch are culpable for selling database technology that is insecure by default, presumably because that's the easiest way to boost their metrics for the VC overlords.

Write being the important keyword

They could have altered the data and no one would have been the wiser

online databases that can be written and deleted by anyone on the internet are no good at all. The data can't be trusted. Of course no welfare for you! All I do is to replace all the names with my name and I can take all the welfare in the whole country! Or for example, doing a search for names and replacing all female names with male names ... how can you trust a database like that?

Making decisions based on a writable database (to the world, and not just from data sources like census, etc) is utterly useless.

Consider Facebook/Twitter as anyone-writable databases. Your comments translate perfectly.

Facebook, Twitter, or even Mediawiki, don't permit any random IP address full database access. (Or had better not.)

Rather, for the first two, large numbers of agents may request access limited to a specific account, with limited capabilities granted.

Even Mediawiki, with an extraordinarily open access model (painfully so in most cases) has checks on extensive abuse, and gradations of permissions.

Suggesting that any of these are comparable to full DBA access as the Meow attack (with considerable merits0 targets suggests an exceeding poor grasp of distinctions or misreading of GP's comment.

You can do better.

Vandalism is not a good public service.

> I’d much rather have my data deleted until it’s secured than have it stolen by someone else

There are multiple logical fallacies in this sentence. First is the use of the world 'until' which is ambiguous here; it suggests that your data can be 'undeleted' after the DB has been secured or you would rather not have any data stored anywhere that is not secured. Either option to me seems like an incorrect read of your comment but I'm not sure. And "than have it stolen by someone else" seems to imply that you know that this data was never copied and cannot be stolen still. I think that seems incorrect, unless there is something I missed that assures everyone that the data could not have been stolen during these hacks.

Lastly, your personally preferred outcome for your personal data is not a measure for all of society, but you grant it that "public service" label as if your preference matters above everyone else's. You don't know what other people think about their data. You don't know what the data even is. What if some of it was just a hobby project for someone, with no financial implications of unsecured data or of data loss, but with emotional attachment to their data? Do they not matter to you?

A blind deletion of unknown data belonging to unknown people is not a public service.

> There are multiple logical fallacies in this sentence.

No, there aren't any fallacies in that sentence and can't be.

The statement expresses a personal preference; to be fallacious there must be some logic that can be unsound. That is, it must start from some premises and then derive a conclusion. To find a fallacy, you have to show that at some point the conclusion does not follow from the premises.

Since it's a simple assertion, it is implicitly sound. (The graph of premises to conclusions is just a single node.) And since the author knows with certainty what his preferences are, we can take it as true. It's fruitless to argue with people about what their preferences are.

> First is the use of the world 'until' which is ambiguous here

Virtually all "fallacies" you see online are just people typing their thoughts in a hurry. Take advantage of interaction and ask them to clarify.

> Lastly, your personally preferred outcome for your personal data is not a measure for all of society, but you grant it that "public service" label as if your preference matters above everyone else's.

And as a member of the public, if it serves my interest, it is a public service to some extent.

Now, fair enough, you're trying to attack it as not being some broader notion of a public service. You have that broader notion in mind, but you don't explain what it is.

Instead you apply your internal definition through "as if..." which puts you in the territory of inventing a claim they simply never made. That's not even fallacious, it's pure fiction.

> A blind deletion of unknown data belonging to unknown people is not a public service.

You do make some claims, mostly coached as questions, that might lead to this conclusion. You never plainly state your premises, nor do you connect them to this conclusion.

So after all that, your conclusion is a non sequitur!

I assume the comment was partially in jest. But this would actually work well if it was consistent and fast. If databases get wiped before you have time to put anything important in them then noone gets hurt.

Yeah, it's bad for the industry right now, but this is just a transition period! Once we get through the pain of losing a few databases, the new steady state where nobody's data is stored in world-writable databases will be better for everyone, and that will be worth the cost.

Consider if this happened five years ago, it would have had a smaller cost than happening today. And it was probably going to happen at some point, so better that it happened five years ago than today. By the same argument, better that it happened now than at any point in the future.

I'm not sure how serious I am about this argument but...at least a little bit? I guess the alternative argument is that any day now software vendors would have all moved to secure-by-default platforms where deploying a world-writable Redis in production would have been so difficult that it rarely happened.

If you have Docker then make sure you have a firewall on top of it, otherwise it will expose pretty much what any docker user wants !

What do you mean by that?

Docker uses it's own iptables rules which have priority over the system ones. Therefore, even if you have an iptables-based firewall blocking all ports, a docker service will still be reachable, unless configured not to be in docker itself.

I do not understand what you mean by "priority over the system ones"

A docker container can have internal ports exposed explicitly, or use host networking. In any case these are ports exposed by the docker-proxy executable - an executable like any other on the system.

Then come the iptables rules of the system (which open or not data flow to the ports exposed by docker-proxy).

Or is it different?

Ah, now I get what you mean - that entries such as

    ACCEPT     tcp  --  anywhere             tcp dpt:8843
are created by docker, independently from the configuration of iptables themselves.

Taking precedence was not the ideal word - it uses the same ip tables, but it inserts its own table as the first one. Therefore it 'ignores' system rules, which might come at a surprise.

> But this would actually work well if it was consistent and fast.

So not too concerned about partition tolerance, huh?

No, think about it, stolen or deleted? Which option serves your clients better given the generally awful situation?

This isn't about benefitting the single organization in the moment. This is about over time, moving everyone towards being more secure.

That depends entirely on the data and the client.

It can be, imagine I saw a fire alarm and pressed the button because I thought a fire started, it didn't and I learnt that the fire alarm only looked like it was working, knowing that this would not be fixed for 24 hrs I choose to smash the alarm so it's visibly broken. Is that vandalism?

If you can't look after people's sensitive data you don't deserve to have it.

I completely missed the poor consistency from the "I would rather" comment above. I would also prefer my data deleted and not stolen, but had to read your comment to realize there is no evidence to suggest that. It is funny how much I assume being at least partially aware of my ignorance of the topic.

>Vandalism is not a good public service.

It is, better than to steal the data, you know what a really bad service is? Let your Database wide open, and expose your customers data (maybe?) for everyone to read.

I'm working on a personal project and not at all related to my work. I accidentally kept ports open :facepalm, sorting things out now :)

First thing I always do on any new VPS is to sort out SSH (disable root login, disable password login), set up fail2ban, install and configure ufw... and if I need to set up something like redis or similar, make sure it only listens to internal connections and also that it is decently auth'd. For deployment and other things I make users that can only write to certain directories; no sudo. It's nothing new or special but it gets lost in distributed systems.

It's a lot more work when doing it in the cloud and spinning up these things from docker containers in K8S...but you're entirely to blame if you don't know what you're deploying and don't understand any of the potential threats.

Do you know of any good resources for learning this stuff? I'm interested in being able to do this sort of thing on a small scale, but there seems to be an awful lot that I don't know I don't know.


What the parent post said is pretty much it in a nutshell, but I use that GitHub for basic Ubuntu server setup.

When is didn't know better, I was always bitten by Docker circumventinging ufw.

Recommend to setup two subnets in your project. One public and one private. This prevents this sort of issues, instances in the private subnet simply don't get a public IP, they can't be reached over the internet.

For reference, the standard practice in a company is to have a (third) separate subnet for databases, with zero internet access (no NAT gateway). Connection must be explicitly opened from/to database clients. It's a nightmare to manage on premise but it works really well in the cloud with firewalls allowing traffic based on instance tags.

> 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 that something like this apparently happens to lots of companies as well.

The only thing I find weird is that ElasticSearch itself does not offer a way to handle authentication, it was just enabled by a plugin that was paid (it seems like its free now).

> The only thing I find weird is that ElasticSearch itself does not offer a way to handle authentication, it was just enabled by a plugin that was paid (it seems like its free now).

"Wierd" is an interesting euphemism for "irresponsible." Defaults are very important. Insecure by default is insecure for 90+% of deployments.

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 upstairs in my office? A perfectly acceptable risk (for me and my files).

I do agree that ElasticSearch do a quite poor/irresponsible job of pointing out their cabinet has no lock. I think Redis do a better job, but are seriously let down by all the internet tutorials that just say "sudo yum install redis" as a minor intermediate step in getting example-todo-list-de-jour working - without even a footnote explaining that anybody who actually visited the redis site now has instructions on how to p0wn your box. ( http://antirez.com/news/96 ) I do think the "Securing Redis" section of this page - https://redis.io/topics/quickstart - deserves to be much closer to the top - I'd have put it before the how to download/install/start instructions myself (though I _think_ recent versions of redis only bind to localhost in the default config, maybe?)

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...

If a thing should not be run in a given configuration then it should not be runnable in that configuration.

The vendor / developer has both awareness and capability to ensure this.

> 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 setting up proper security.

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.

ElasticSearch does offer authentication.

Most of our services were created like a POC & deployed to production, & I joined my company fairly recently.

We had a planned release this week to secure ES. And Saturday, we got "meow"ed

Regarding elasticsearch, that’s actually fine.

Just block access to it on your firewall to the public ports and require people SSH or VPN for access if needed.

It’s not

Where can I find a tutorial or a guide about it for, let's say, Ubuntu? Would this be a good start: https://www.digitalocean.com/docs/networking/vpc/how-to/enab...

The DO tutorial is a good start, but as another poster mentioned further down, check out: https://github.com/konstruktoid/hardening

note: the DO tutorial will hold your hand a little; the hardening doc expects a (minor) degree of familiarity

Thanks. I saw this git repo earlier and it looks interesting (even though most of my machines are on LTS 18).

I don't see anything about subnets in there though. Did I miss something?

> It's a nightmare to manage on premise but it works really well in the cloud with firewalls allowing traffic based on instance tags.

It's not though. Subnetting and firewalling are like the foundation of any corporate network.

Issue is with AWS this setup instantaneously bumps the bill up from a few dollars a month to a few tens of dollars a month. Deal-breaker for personal projects. But, you can still secure the database with whitelisted IP addresses, which is what I do.

The top-voted answer links to this HN page. I'm stuck in an infinite loop.

Nah, you're just in an unbounded recursion - don't worry, I can already now tell you that it ends with stack overflow.

I dunno, does Chrome implement tail call optimization? :)

Nah stack overflow learned their lesson and switched over to free monads.

Ha! Clever!

You should configure a timeout.

You can cheese infinite loop detection by setting a max number of edge traversals (that way you don't just loop longer when someone speeds up the happy path).

For real code, you wouldn't generate a web page with 5 million entries in it, so you can be pretty sure that the data is bad even if it's not cyclical (but it probably is)

Good tree^H^H^H^Hgraph traversal algorithms have a history stack specifically to detect and deal with loops.


If we pretend we're using readline here, ^W (yank previous word) and ^U (yank to the start of the line) should save you some key presses.

Some recommended bedtime reading:



These are not emacs commands. They aren't even unix shell commands. They are TTY commands, some of them dating back to the dot matrix teletype terminals.

My favorite is ^U, which 90% of the time lets you start over on a password prompt when you are sure you just fat fingered but not sure how badly.

Thank you, that one is really useful! The one I had always remembered was ^H for whenever no other way to delete characters works. I need it in some SQL REPLs which aren't configurable.

I think you might be conflating these (or maybe I should say the gp is). Nevertheless.

Do you have a reference to the history of key combos like ctrl f, b, n, p and a and e? Those are typically referred to as emacs style navigation and I am genuinely unaware of history of those as common tty control codes outside of emacs for cursor movement. They weren’t dec vt control codes. Ctrl-U was though and even has ASCII assignment as “NAK”. Ctrl-H and C are similar.. but people don’t typically refer to those as “emacs” keys.

> Do you have a reference to the history of key combos like ctrl f, b, n, p and a and e? Those are typically referred to as emacs style navigation and I am genuinely unaware of history of those as common tty control codes outside of emacs for cursor movement.

I've always heard of it as an ASCII control character and gets its history from Unix interpretations of really old IBM keyboards which got its history from typewriters. I've literally never used emacs for anything other than ^X to exit; I'd rather use cat than emacs. I use vim. But ^H has worked for me as intended on a serial console and on telnet.

Some diving through wikipedia:

[0] says: Pressing the backspace key on a computer terminal would generate the ASCII code 08, BS or Backspace, a control code which would delete the preceding character. That control code could also be accessed by pressing Control-H, as H is the eighth letter of the Latin alphabet.

[1] says: In some typewriters, a typist would, for example, type a lowercase letter A with acute accent (á) by typing a lowercase letter A, backspace, and then the acute accent key. This technique (also known as overstrike) is the basis for such spacing modifiers in computer character sets such as the ASCII caret (^, for the circumflex accent).

[2] says: Unix (command line and programs using readline): Ctrl+H = Delete previous character

[3] supports [0] and says: Caret notation is a notation for control characters in ASCII. The notation assigns ^A to control-code 1, sequentially through the alphabet to ^Z assigned to control-code 26 (0x1A). Often a control character can be typed on a keyboard by holding down the Ctrl and typing the character shown after the caret.

However, it's worth noting that it also says The meaning or interpretation of, or response to the individual control-codes is not prescribed by the caret notation.

But, despite that, ASCII describes control character 8 as backspace [4] [5].

According to this Wikipedia article, work on ASCII began in 1960 and its first release in 1963 [6].

Emacs' first release was in 1985 [7].

I suggest that perhaps in your bubble control sequences are referred to as emacs style navigation even if it's not necessarily the most historically accurate. I'm glad you're working with *nix enough to be familiar with emacs and there's always new old things to learn. There's a lot of history to learn and understand.

[0] https://en.wikipedia.org/wiki/Backspace#%5EH

[1] https://en.wikipedia.org/wiki/%5EH

[2] https://en.wikipedia.org/wiki/Control_key#Table_of_examples

[3] https://en.wikipedia.org/wiki/Caret_notation

[4] https://en.wikipedia.org/wiki/Control_character#In_ASCII

[5] https://en.wikipedia.org/wiki/ASCII_control_characters#Delet...

[6] https://en.wikipedia.org/wiki/ASCII

[7] https://en.wikipedia.org/wiki/Emacs

Oh boy, was that a rabbit hole.

I read your post and thought, "I've misremembered the story."

But the Wikipedia page for the Teletype-33 claims that it 1) had control characters, and 2) was inspiration for some of the ASCII character set, which was defined later in the same year:


1) If it‘s a tree, it ain‘t got no loops 2) The stack isn‘t to deal with loops, the „visited“ flag at each edge is there for that. The stack (for DFS, BFS would be a queue) is there to keep track of which nodes have been visited such that you can construct a path from the starting node to the one you‘re looking for.

Obviously there are variants to this, depending on what you‘re actually trying to achieve with it. My point is that a stack would be a very inefficient way to deal with loops.

Modifying the graph turns it into shared (mutable) state. Your code is still re-entrant, but it's no longer concurrent.

1) you're right, I edited my message to reflect that I meant a graph traversal algorithm.

2) a visited flag on an edge? That won't support simultaneous traversals. Keeping a stack is a lot more efficient than permitting only one traversal at a time.

I‘m not sure why you‘re bringing concurrency to the table.

My point still is that looking something up in a stack (did I visit this node?) costs O(n) time, so the BFS will degrade from O(m+n) to O(m*n+n).

To come back to the concurrency, if you can index your edges in some way, you can also store the visited flag in a separate datastracture to support concurrent access (one „flag store“ for each access).

> I‘m not sure why you‘re bringing concurrency to the table.

Not using data structures that enable concurrency prevents performance improvements since modern hardware is, in general, more parallel than vertical.

I hate to laugh when people's hard work is being destroyed, but this is some impressive trolling by the attacker:

> An interesting theory as to why the attacker used the term "meow" is because cats like to drop (or knock) items from tables.

I hadn't considered this. I'm enjoying this even more.

Atlassian is not on Google Cloud, they are an AWS shop. I suspect this is an unrelated personal project.

How much would you bet against that guy having fairly highly privileged AWS IAM access in Atlassian's account?

I worked at Atlassian and have a high degree of trust in their production accounts.

Atlassian's IAM privileges were pretty damn strict from what I remember when working there.

If meant as a public service, it would have been much less destructive to use the change passwords API [0] to set random passwords for all of the users.

[0] https://www.elastic.co/guide/en/elasticsearch/reference/curr...

Given that "unsecured" means "data are accessible and modifiable by anyone", creating tremendous externalities for all referenced in the data, , I'm happy with deletion.


One of the first publicly known examples of a Meow attack is an Elasticsearch database belonging to a VPN provider that claimed not to keep any logs.

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?

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?

Parent's point is that any conclusion one could make from the data is worthless because, being public and unsecured, it could have been modified by any Internet user at any time before a password was set.


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

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.

Something tells me that this level of pain would prove insufficient for education.

I wonder how much customer info they were leaking before then.

The question was posted early Friday morning. If this drove their services, I suspect a lot of us would've known about it a lot sooner than now...

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 wouldn't otherwise have been secured which are now spared from not only destruction but theft.

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 are (partially) to blame here.

Well, it's just another attempt at monetizing the product. Nowadays, companies and developers expect everything to be OSS (and I love it) yet it's incredibly expensive to develop SW (and very few people do OSS just because of passion--I tried and failed miserably).

Locking RBAC and TLS behind a paid subscription is a sure way to force companies with security teams to pay for it (or not to use it).

This particular lesson comes relatively cheap--dropping your data is not the worst an attacker could do with it. Hopefully, more people will research what I'd call "security 101"...

> yet it's incredibly expensive to develop SW

It _can_ be. At the same time some of the most used software in the world manages just fine without a company running paid subscription plans and locking free users out of critical security components.

ElasticSearch/MongoDB/Redis et al are trying a new model for how to create OSS with a company behind it funding all/most of the development. That's OK, and I'm super interested to see how it works out long term. But there are many many counter examples of similar sized or way bigger software projects that never needed to do this. Pretty much everything that those three databases depend on to be used in applications is OSS that never had a "paid subscription" locking access up. How useful would any of them be without Linux, or Apache/Nginx, or Ruby/Python/PHP/Perl.

My fear is that half-assed-OSS that does a _great_ job of "capturing developer mindshare" but a lousy job of securing free use of their software - is one day going to be the root cause of some _spectacularly expensive_ data breach, after which pointy haired bosses and less technical C suite suits are going to feel the full power of Oracle's golf-course-and-expensive-restaurant marketing army, and nobody in a company bigger than 10 or 12 people will ever be able to use any database with less that a half million a year license because "due diligence!" and "risk mitigation!" (and "Waygu steak with expensive whiskey" and "dirty free software hippies exposing you to data breaches!!!")

> Well, it's just another attempt at monetizing the product.

Don't make excuses for their shitty business practices.

The thing is that no one cares. It's a cultural issue. If Elastic makes it "harder" to get off the starting line by setting secure defaults, they'll get their lunch eaten by a fork called EasyElastic that people perceive as "easier".

This probably isn't an excuse for Elastic anymore, but it's how Elastic was born ("easier than Solr!" -- they didn't invent full-text search, after all) and it's how whatever supplants Elastic will be born. Why is MySQL dominant over Postgres even though "referential integrity" didn't come to the game until v5? Why Docker over jails or OpenVZ? etc. People adopt technology because it's fashionable and it becomes fashionable in part because it's perceived as easy to use. Security and ease-of-use are not quite true opposites, but there's definitely some intrinsic tension.

We have a lot of hapless practitioners in the space and the root problems here won't go away until we get some standards. Better solutions usually lose because crappy stuff focuses more effort on marketing and an "easy" onboarding process, where better stuff focuses on the operational complications of the real world.

Don't tell people what to do.

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

Curious, why do you use Mongo? Does it give you something that a JSONB column in Postgres wouldn’t?

I use jsonb heavily. While it is amazing, I definitely wouldn’t rely on it as a general purpose replacement for NoSQL/schemaless data storage.

An example of an issue I am dealing with currently: while you can create a gin index to speed up containment queries, Postgres doesn’t keep any statistics about jsonb columns. This means the query planner will sometimes do stupid things, like using the index even for very non-selective overlap conditions, which is a lot slower than just doing a sequential scan.

Less of an issue for me but worth considering: the size of the gin index in my use case seems to be about 5x bigger than the size of the unindexed data. I was surprised by the size increase. I only use the containment operator so I could make a smaller/faster index using the jsonb_path_ops operator class. This is on my todo list :)

Like all non-btree indexes in Postgres, the index is unordered. That means sorting by values in the jsonb column will always be slow. This doesn’t matter for selective queries, but exacerbates my already slow non-selective queries that return large result sets.

That said, if your queries are selective, jsonb + gin indexes are surprisingly performant (in the 0.5-10ms range for small result sets). My use case is a mix of structured relational data with jsonb for user-defined values (which of course they want to use for querying/sorting and I was dumb enough to say “sure, why not?”)

In terms of the magnitude of data, there’s roughly 10 million rows. Each team using this service has the query scoped to about 500k-1 million records, and then additional filters (on the jsonb column) will scope that down to anywhere between 60k-0 results.

Thanks for the detailed response. I'm curious, is the NoSQL store a canonical store of its own data? If not, how do you replicate from postgres to the secondary store?

I ask because where I work we sync postgres to a secondary store for search, but the way it's done in a piecemeal, application-specific way gives me the heebie jeebies. It almost certainly will result in that secondary store drifting. Unfortunately we can't use something like zombodb [1] as we're on amazon RDS. It seems like you know your stuff, and seeing non-deterministic consistency irritates the heck out of me!

[1] https://github.com/zombodb/zombodb

Maybe they have 10 years of code sitting on it? It's what a colleague calls sound historical reasons.

A JSONB column in Postgres doesn't have:

- Proper replication in its first-class, default configuration

- Automatically managed cluster membership

- Seamless automated failover

- First-class async client libraries in many languages

- A non-awful query language

Focusing on the JSON is beside the point (though it is a convenience). Wake me up when you've got a properly distributed database.

Thank you for raising this question. Well, for my things I use MongoDB because of very convenient integration with programming languages (Go, C++ via Mongo C++) and zero hassle with schema

But I'll be happy to replace it by something else, my load is extremely small and only single requirement is to have DB as network daemon, not as embedded storage as it will be used by 2 applications (main daemon an API).

RethinkDB was really nice candidate for it but it's not alive anymore: https://rethinkdb.com/blog/rethinkdb-shutdown/

If you have ever used Mongo Atlas, you would understand why people use mongo. The administration ease that the platform provides is unmatched by any other DBaaS I am aware of.

Surprisingly, I feel Mongo has been kind of surging back into developers' minds. I thought Mongo was utterly dead, and I also don't know why would one use Mongo instead of JSONB. The last I heard (3-4 years ago?), there were some fundamental problems with Mongo.

That said, I've incidentally heard a lot about Mongo in the last half a year. Might be my bubble. Might be MongoDB actually maturing and getting really good. I hope it's the latter.

I mostly hear complaints about email spam from their salespeople.

Yes, hipster cred.

For everyone else, JUP ("Just Use Postgres")

Snark aside, Postgres should hold you over for quite some time.

With Postgres you probably don't need Redis, Elastic Search, Mongo or Kafka.

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

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

Seriously this is the most annoying thing ever, especially if someone on your team things you need to expose the ports to redis in a docker compose. I’ve come back from a weekend where my redis instance was being used for crypto mining.

Anything that is insecure by default in 2020 should be killed off IMO.

Isn’t exposing ports in your docker-compose services:redis:ports, how you’d do that? (Docker hobbyist here)

My guess would be that they went with "ports" instead of "expose" which makes it public. But even with careful composition of your docker-compose you might want to be careful, Docker can interact with iptables in surprising ways and long iptables rulesets are almost comically difficult to validate sometimes. The result is that if you're using both Docker (and even more if you use Compose, Kubernetes, some other orchestrator) and doing anything else with iptables (including using it as a host firewall) you need to take a lot of caution to make sure you don't mess anything up. These tools usually confine their changes to custom chains to make this stuff easier to sort out but at the same time it can make it more difficult to understand what's happening, particularly with the use of tagging and etc.

In general I would recommend putting some kind of protection between machines running Docker (and especially orchestrators) and the internet. This could be cloud provider mechanisms (security groups, ACLs, etc), a firewall appliance, NAT gateway configuration, etc. depending on the situation. It's not necessary, but it makes the situation easier to audit/validate, and more layers of protection seldom hurt. If nothing else it means that much of the time you'll need to make a mistake in two places instead of one, in order to have an unintended exposure.

"and long iptables rulesets are almost comically difficult to validate sometimes."

Use nmap to evaluate your policy from the outside, don't try to validate it in your head by inspection.

Use Shodan.io’s monitor feature and you’ll get alerting, too.

Friendly FYI, "EXPOSE" is a no-op that is only meant as visual documentation to end-users.

  "The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published."
Second paragraph:


I'm referring to docker-compose, where 'port' and 'expose' are container configuration options that behave differently from the Dockerfile keyword.

Although the similar words with different meanings no doubt contribute to confusion.

Ah, my mistake. That comes off pretty asinine then, apologies.

Secure by default is super onerous though. What if I just want to try out something before committing to it, do I really need to jump through a bunch of security hoops?

Of course you don't need to waste time setting up security properly. And it's such a pain locking and unlocking your car and your house every time you go in and out too. Tell me, where do you live again?

I'm 58 and bald, so channeling yoda is easy: a valuable lesson you need to learn, and learn it the cheap way or the expensive way you can.

The cheap way is to invest in a cheap VPS for a month, fire up sshd and a webserver, and then check the logs when the month is up.

The expensive way is to carry on treating security as an afterthought. It'll cost you your pride, your reputation, and possibly your career.

Absolutely. Laziness isn't an excuse for not caring about security. Security should be the top of your mind any time you connect anything to the internet.

The fact it's not, is why we're seeing major attacks/leaks/etc almost every single day now.

Right, well now we know why secure by default isn't a thing. If your product is super onerous to use, people will switch to a competitor that is easier to work with.

A secure by default product is a dead on arrival product.

Then you just pass the `--disable-all-security` flag. (Or whatever similar method the project you're using exposes to allow that.) Secure-by-default doesn't have to be complicated; it's just a way to ensure people don't shoot themselves in the foot without comprehending what they're doing.

Thank you for this reply; it's my favorite post in the entire discussion. It illustrates perfectly why insecure defaults are a terrible way to implement "tutorial mode".

Exactly. Do people complain about how hard it is to spin up mysql or postgres?

Yes, so that you always keep security in mind.

And what if the thing I'm building isn't intended for the public internet?

Then why are you building it on the public internet?

I'm not. I'm just using flask/mongodb/whatever for some internal app. But if it's secure by default I need to jump through a bunch of hoops to secure something that won't even be on the public internet.

Yes, this is terrible, and when I discovered this, I was appalled how it seemed no one was taking this seriously.

When you use ufw with a default DENY policy, you tend to assume that whatever isn't explicitly listed gets DENIED. This is not the case with Docker, and I think it's just a matter of time until someone loses big because of this issue.

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.

link for the missing DOCKER-USER chain: https://github.com/docker/for-linux/issues/810 - so if you are unlucky you are one apt upgrade away from data theft...

Apparently these guys don't have a firewall setup and haven't heard about private networks and VPNs.

reads TFA again Wait, one of the victims is a VPN provider???

I've read that there are now VPN providers that just use someone else's VPN engine. So they don't have to know wtf they are doing.

For a product that's 50% snakeoil and marketing, that approach seems reasonable? It's easier than actually doing the leg work.

Only 50%? I'd put it much closer to 100% tbh. Why people are so eager to funnel all their traffic through some of the shadiest businesses on the Internet is beyond me...

That's just victim blaming. The same logic applies to every crime: "lock your doors if you don't want your TV to be stolen!".

It also works at any level of security: "Lock your doors and hire guards if you don't want clever thieves breaking a window..."

But if you require everyone to take adequate measures to physically secure their houses, you don't even need laws and morality!

And while this may provide the sort of negative reinforcement you are hoping for, actual damages in each case are going to be all over the place. That makes this one of the worst possible punishments. Imagine the penalty for speeding is a random outcome somewhere between a stern reminder and the death penality. There would be nothing fair and little useful about that, even though it does follow the same basic principle of do bad -> be harmed.

You're not thinking of the right victim. You're considering the organizations who compiled the databases in question. If the databases are composed entirely of their own information that they created themselves, then sure they've suffered a loss. In most cases, however, these databases include privacy-sensitive personal information about the customers of the organization. Those customers have been victims of bad security practices ever since MongoDb was first installed, and this "meow" hack has ended their victimization.

> But if you require everyone to take adequate measures to physically secure their houses, you don't even need laws and morality!

If laws and morality were sufficient protection against malicious actors, I might agree with you.

However, in a world where cyber vandals are often beyond any accessible jurisdiction (and may even be supported by their local authorities), laws and morality are clearly not effective at keeping unauthorized users out of private systems. As such, the responsibility for keeping private information secure naturally falls on the people running the systems.

Putting up a network firewall (or at least requiring authentication) would have prevented the damage described in the OP, and is a rudimentary security measure that has been common practice for decades. The people who suffered significant damage from this attack should strongly consider outsourcing system administration to someone who knows what they're doing.

the truth is in the middle you have to take some responsibility, but yes of course some blame goes to those who also make it possible. If people just throw their hands up and say they're victims and have no responsibility to secure their systems then they will always be victims.

Why not just rename all the tables or something? That's enough to get the developer's attention without being so destructive.

My website once started failing because someone had connected to redis and set a password on it. That was the day I found out the redis docker container accepts everything that can connect to it unauthenticated by default.

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).

That sounds reasonable, but you'd think most people would also be concerned about their databases being publicly accessible in the first place, yet here we are.

I don't think this is the case of people not being concerned, but simply the ignorance on their part about the setup. People just presume that the defaults are safe, and never bother getting into the details.

At the risk of arguing "no true Scotsman," someone who is concerned about security likely wouldn't make assumptions about defaults. Or rather, someone appropriately paranoid about security concerns would not trust defaults without at least reviewing them.

Not everyone feels comfortable and/or knowledgeable enough to review the settings. What they really should do is to hire an admin/devops consultant, but for so many projects it's just not a realistic expectation. That's why I put all the blame on developers who chose to publish the software that's unsafe by the default. It's done on purpose for marketing/sales reasons, to make onboarding faster and easier and get as many users as possible with "simple to start using" service, at the cost of putting users in danger later on.

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

Which is precisely why it is ok for me to enter your unsecured garage window and slash all your tires.

Because some people just want to watch the world burn.

What about developers just being competent before deploying a database on the public internet?

At least google "securing X" before just pumping data in.

How about all professionals in every industry being competent before doing anything? Then we wouldn't have any issues in society.

Strawman. And a weak one at that. Fuck off with conflating the minimum amount of competency needed to secure the data you needlessly collect with that kind of naivete.

Who says every unsecured db on the internet consists of "needlessly collected" data?

This reminds me of "crackit"[0] from a few years ago with Redis. A lot of folks kept their Redis server bound to with no firewall or published port 6379 by "accident" with Docker and by default Redis uses no password. It was a lot worse than meow because with some Redis configuration magic anyone could inject their own SSH keys onto the server.

This article says Redis is affected but I would be curious to see which version of Redis was being used because they changed their default configuration after crackit was wide spread.

[0]: http://antirez.com/news/96

Yeah one thing though with Docker is that in some cases it injects its rules into iptables before the firewall application's.

I was using arno-iptables-firewall and this suffered from that, docker containers would be world accessible. In general I only bind them to localhost anyway, but I figured this out when testing. It doesn't seem to happen with UFW.

But I can imagine some people know how to set up a firewall but then just assume it works and don't check. This is the kind I do feel sorry for, at least they tried to protect it.

There were several redis remote execution holes, not just the config file one, so pretty much anybody with an open redis was going to get trouble.


Currently there is crypto mining malware infecting exposed Redis servers (kdevtmpfsi)

This happened to me. Was just getting started with docker and got everything working and a few months later someone had set a password on my redis database. Who knows what else happened before that.

Ended up deleting the server.

This is what happens when you lay off all of your sysadmins because "the cloud", move that role to devops and then downsize that to a subduty of a developer.

I’ve seen just as many sysadmins do this as developers. It’s not a question of job title as a psychological pitfall (people who are looking for things to succeed don’t ask when they should fail) and companies not specifically retaining people with security experience because they cost more.

It can be though. Downsizing and getting rid of specialists certainly hurts companies. There are only so many hours in the day and that desperate guy working 14-16 hours a day because of covid downsizing is eventually going to eff up no matter how talented she is.

I’m not sure exactly what you’re disagreeing with. My point was just that it’s not useful to direct criticism at a job title when there are so many examples of failures by people with any given title. I’ve seen people who are ostensibly pen-testers or auditors blithely telling others to click through important warnings or have a root-on-all-machines password to make their work easier.

Downsizing and other false economies are definitely a contributing factor. Security and reliability are easy to dismiss as expensive overhead until they suddenly aren’t.

Every cloud database provider I can think of gives you random initial credentials from the getgo

i'm sure it's not that. most likely they are databases that development setup for testing or developing a quick server and just forgot to hand it over to sysops or dbas. happened all the time where i use to work.

But the profits...

Somehow I feel good about this. The article claims nothing good can come of deleting exposed databases, but I strongly disagree - I'd by far rather my data be deleted than stolen and shared. If the owner doesn't have proper backups AND can't secure a database, they have no business hosting such data, period. IMHO.

I think this is a little simplistic. Depending on what data is being deleted, it may have real life economic consequences for individual people. What if one of the databases has a record of credits you've purchased at your local spin studio? Hopefully they have a back up, but if they don't, you and/or the owners stand to make significant losses. Are there databases that could be lost without consequence except to their owner? Sure. But that is far from all of them.

I also just think it is a little uncharitable to wish harm on people simply because whoever did their IT was inexpert at their job? Like, how does the local mom and pop correctly evaluate a person's IT chops? The nephew says they can set up their website for cheap, and they want to be nice, so they give him the job. Turns out he's a newb and later their database gets deleted and you are on here saying that's a good thing? Hrm. I don't agree.

It can definitely have real world consequences, but couldn't the same be said for somebody being a whistleblower for a company that doesn't following building codes? The company could take a huge financial hit and people might lose their jobs because of their practices being exposed.

Sometimes the best path forward does harm, sure. It's just hard for me to agree that deleting these databases is the harm-minimizing path. One example of a less harmful path that comes to mind immediately is installing a random password on the unsecured database and emailing the domain owner the password. That would cause downtime but it would limit the irreversible damage. You could even say that you will delete the database if it is found again with an unsecured password, if you wanted to add some stick to your carrot. It does not seem like this attack has harm-minimization in mind.

What you propose is illegal in most 1st/2nd world countries. In mine, the company could thank you and then put you straight to jail for 30 years. Unfortunately very few small businesses run sade reporting programs and often react with attack.

So is deleting a database.

Putting a password and emailing the admin would solve the password problem.

But I agree doing anything is probably illegal. I would leave it... not worth hassle of wearing the superman cape.

The problem is with the e-mailing part. A mom&pop is unlikely to track you down if you lock out their DB, but they'll likely report you to police if you contact them about it.

Is an email from an anonymous address easier to trace than remote database commands?

Yes. You need good logging on the vulnerable DB to trace the command - and if your DB is vulnerable it's a good bet you forgot the logging too.

Emails have a bunch of info in the headers, so there is more meta-data in the email it self.

Neither is perfect for finding the culprit but one scenario has zero meta-data and the other has some.

How about simply emailing the admin to tell them their database is unsecured? Oh, but that would be benign; I'm sure vandalism is so much more fun.

Unfortunately it's rarely that simple. If you look at the currently exposed MongoDB instances you'll see that most of them are in the cloud without any obvious attribution. You could email the cloud providers and see if they will reach out to the end-user but chances are they already know about it. Here's an article I wrote on that subject, although it was related to industrial control systems:


“Fix auth”. Add item to todo list and just forget because there are other more pressing tasks to do.

It's easy to say "you could have just emailed them" when you are not the one doing this for years without things getting better. Often admins flat out ignore you. Even if not they usually do nothing. And if they do something it takes ages.

I don't doubt that for a moment; I have also reported issues of various kinds -- not this specific one -- that have gone unresolved for ages.

That still doesn't justify vandalism.

In the article one provider was notified that their database was without a password an publicly accessible.

They secured it, and somehow managed to make it publicly accessible again without password, this time it got hit by this attack.

Honestly this is like if a company decides to keep their paper records with my information on a public side walk, and somebody saw that and decided to bring them to the landfill.

Is it legal or fair? In a perfect world no, but at this point the company is not blameless.

I certainly think the most legal approach is to do nothing except notify, or maybe nothing at all. But if you must modify the database, locking it reversibly is more defensible morally.

Or just set everyone's password to the same thing eg SecureMe

>> but couldn't the same be said for somebody being a whistleblower for a company that doesn't following building codes?

No. The equivalent would be exploiting their buildings weakness to cause them to collapse - maybe with people in them.

Pointing out a vulnerability is not the same as demonstrating it.

That said, a demonstration will get their attention more.

Your comparison isn't fair - blowing the whistle is supposed to be a last resort. Internal disclosure and attempting to fix the issue collaboratively is always the first step.

This attack is indiscriminate and is without warning, so it eliminates the possibility for database owners to fix the problem in good faith.

Finally, after years and years and years of being told over and over and the bottom line never improving.

I got doxxed with the Equifax breach. How many other companies in the world will take someone's word that they are me based on that data, and what potential is there for my life amongst millions of others to go completely sideways because of companies who won't addmit the systems are broken?

I say the house is already burning, but maybe throwing some fireworks into the blaze will convince the right parties to finally put the damn fire out.

Beyond sick and tired of breach after breach after breach after "oh, there were millions of voter records showing publicly" "no, <insert product name> defaults to no security"

Just because it's understandable for Mom & Pop to not care about the privacy of the people whose data they've collected doesn't make it a good idea. They should care. If the buck doesn't stop with business owners, with whom does it stop?

IMO we specialize too much and miss important things that we mentally outsource to other people. I'm equally disturbed how often I meet people in tech who are unable to do basic home repairs or cook for themselves. Something, like say, a few weeks of quarantine, and people's anxiety goes through the roof because they've relied on other people for basic life skills.

I don't find your example very convincing. Any database storing personal data needs to be properly secured, and if that gym also has ID credit card or other more sensitive data, that data might better be destroyed than stolen.

If it's a publicly accessible wiki with no sensitive data whatsoever, and that's meant to be publicly accessible, then there's a reasonable excuse for the poor security and it's not helping anyone to destroy it.

There is no indication in this article that all of the databases had personal data.

Why should innocent users be punished? Why not just send a pic confirming you have full db access? This is just unnecessary vandalism.

The point is that, if my credit card info is staying in a web-exposed, insecure DB, it is safer for me that it be destroyed than left alone.

I have no idea of that is the intention of the attackers, or if they are maybe even stealing the info before deleting it. But assuming they were good Samaritans and just deleting it, that is the best outcome for me as a user, better than if it stayed up for another day.

Because often that doesn’t actually elicit change. Deleting the data over and over does.

Somehow that would be worse. Feels like a ransom call.

What happens when mom & pop are storing your name and credit card # in plain text and then your identity gets stolen and credit ruined? Should we still be "charitable" to them and their d-bag nephew?

Your credit card number being stolen is a problem for your bank, not a problem for you. You can't steal someone's identity with a credit card number.

The concern in this case is when there is some social problem with being in Mom & Pop Inc's customer database. There are probably some people that buy some things that they don't want other people to know about. When the database gets hacked and you are linked to being their customer, that is the unfortunate and potentially damaging information leak. A credit card just gets reissued and the bank reverses the transaction. No big deal.

It's a problem for the vendors, not the banks. They get hit with chargebacks for fraud that's no fault of their own, hurting the whole ecosystem of vendors and their customers.


The problem could be easily solved by Visa/MC/Discover/Amex implementing chip and pin, or at least 2FA SMS authorization. Bestbuy.com has it working somehow.

These people can't configure a firewall. How are they going to implement payments in the secure fashion you suggest?

I meant that Visa/MC/Discover/AmEx should be forcing the use of chip and Pin or other 2FA methods.

> Your credit card number being stolen is a problem for your bank, not a problem for you.

Not necessarily, depending on where you're based.

It's still a PITA when my credit card has to be swapped.

Ye it is not like I trust my credit card to strangers and let them walk away with it for a while.

Like, how does the local mom and pop correctly evaluate a person's IT chops?

Usually by price and unfortunately both mom and pop like a bargain - I've seen this play out more times than I would like.

Also how do you evaluate, say, a landscaper's chops? Or any other kind of contractor's for that matter? By doing research beforehand, checking what kind of reputation that person has etc.

Low-effort or lack of research gives you bad services, for which you pay in losses like these.

In construction and landscaping work those companies are usually licensed, bonded and insured. If they fuck up the work there's obvious financial recourse. Also, the measure of them fucking up is generally a lot clearer for physical labor and for mom and pop businesses, getting construction work inspected by a 3rd party is usually more straightforward and cheaper.

In software, financial recourse generally means you have to jump straight to lawsuits. There's no licensing for who's qualified to build a website, developers don't have to escrow funds or carry malpractice insurance in case they make a mistake, a development business should have insurance in place but there's not always easy or affordable ways to assign fault in most IT situations if you want to pursue them. Software and IT forensics are prohibitively costly and usually mean a lot of money has to be on the line which rule out mom and pop businesses entirely. IT and software mistakes also usually take longer to rear their heads, and people in IT and software also aren't known for sticking around for decades. How do you sue an LLC that dissolved 5 years ago?

It's apples and oranges in my opinion.

If someone does a shitty job in home improvement stuff it's usually not visible for years down the line. And good luck with your recourse by then. I've never heard of a homeowner getting recourse unless it's insanely obviously bad right away. The vast majority end up just living with the defects or hiring someone else to do the job again.

10-years warranty is a thing and is mandatory in some places/countries.

I don't how it is in the US, but in my country an audit that would reveal such an obvious lack of security costs no more than the equivalent of a single minimum salary - usually much less. On top of that several companies that offer such services are widely known because their media presence is mostly articles about vulnerabilities in routers, phones, operating systems etc.

I hail from a post-communist country so I assumed the culture in the US is more developed in this regard.

I'm not sure what your country's going rates are but for the US, a small business might budget a few thousand dollars total for their website. A minimal security audit that would catch missing or stupid security would basically double their expenses. Unless they truly needed some custom feature they'd take one look at a security auditor's quotes and then go sign up for Wix or Squarespace immediately. It's not that the services don't exist, its just that they're expensive and typical non-technology business websites don't really need that much put into them.

If regular citizens of your nation can get a COVID test back in less than two weeks, you should consider yourselves more developed than USA.

I am thinking more about the clients of the mom and pop shop who are better off not having their personal details exposed.

> Are there databases that could be lost without consequence except to their owner

I would certainly hope the owner of the insecure database would face massive consequences. IMO there's not _nearly_ enough of that. This sort of breach should be financially ruinous for _any_ company.

What if the database only contains my blog posts? Or my own personal health information I'm tracking? Or all the Hearthstone cards? Or any other of the infinite data sets that are totally insignificant to anyone beyond the owner of the database?

Not everything is about you, and also you totally misunderstood the post you quoted.

Then you'll learn real quick to secure your database, make backups, or not post personal stuff online.

And if you've configured your database that poorly, am I supposed to assume you've properly configured your server against becoming part of a DDoS attack? Or a bot net? The base level of negligence you're defending enables a multitude of attacks. Losing your DB would be an immediate sign you don't know what you're doing, and thus shouldn't be doing it.

The possibility of someone stealing your identity (or worse) far outweighs the damages from losing some coupons.

Deleting exposed databases is genious, there need to be real repercussions for companies if they leak user data.

> The possibility of someone stealing your identity (or worse) far outweighs the damages from losing some coupons.

That is a very rich person statement.

Fine, what about every poor person who gets their data stolen from an unsecured database, and gets their identity stolen?

Yours is also a rich person statement.

Unsecured databases are a huge loss for everyone.

Anything that forces a shift in this naive behavior of vendors, implementors and executives is not just fine by me, I welcome it. If my life suffers because of data of mine that's lost from companies' databases, I now know who to cease doing business with.

Not really, it's much easier for rich people to reclaim their identity than it is for poor people.

But what about the companies making millions in profit each year that are carelessly exposing sensitive data because they don't want to spend a little more on quality IT work?

No one wants to see their local pizza shop lose their pizza-credit database, but if that's the price to pay for data security then so be it.

> What if one of the databases has a record of credits you've purchased at your local spin studio?

Usually when you buy something, you get an email receipt. So you print out your email receipt and go to the mom and pop store.

Given they are a local mom and pop store, you likely have a long term relationship with them and they may even remember you buying credits. So it will be a hassle, but likely ok.

It is the huge corporate stores that don’t have long term relationships that would be hurt by this thing the most.

Depending on what data is being deleted, not deleting it could also have significantly worse consequences when it later falls into the wrong hands.

In the case of the spin studio, you can prove what you paid, the owner just lost his evidence of what he no longer owes you, and will hopefully in the future stop exposing your personal data on the Internet.

> Like, how does the local mom and pop correctly evaluate a person's IT chops?

Not my problem.

> The nephew says they can set up their website for cheap, and they want to be nice, so they give him the job. Turns out he's a newb and later their database gets deleted and you are on here saying that's a good thing? Hrm. I don't agree.

Mom and pop prefer nepotism over skill, credentials and reputation, without even a second opinion. There is a reason that this is frowned upon (and has been for at least some 2000 years before mom and pop were born), regardless of the domain.

On the off chance that their database doesn't contain any personally identifying information on their customers, this is an idiot tax. In any other case, their loss is completely justified when compared to the potential losses, abuse and manipulation of their customers that come with exposing their PII to the public.

lol im sorry but this is probably not the best go-to example of real world consequences:

> What if one of the databases has a record of credits you've purchased at your local spin studio?

p.s. bobby tables did it first

A spin class? Really that is the best example you can come up with? That is not at all compelling.

What part of the example do you dispute? Spin studios have databases, like almost all small businesses these days.

If I knew we were frying fish this small Id a brought a different pan

4000 small fish is a lot of biomass.

No other bad actors can get it, but we don't know if it's already been found, and now that it's gone we have no idea what data is out in the wild. And as you note, we can't trust the companies to accurately report it themselves.

I think you make an important point though - deleted or not, there is no real way to know what's been exposed, and no guarantee that they'll ever admit it; so torch all the data expeditiously, and we'll just have to comb through 'successful' leaks just as always.

Another side is that with their database blanked, that will force more companies to explain their downtime or complete loss of data, rather than quietly secure it again and pretend nothing happened

Maybe this actor A downloaded the data, then deleted the database, preventing others from accessing and selling the same data? Only A can sell this data now?

So, no difference other than the company now has to explain that their database was insecure. Got it.

maybe the authors of meow should "improve" it with a feature that reports every instance to HIBP before deleting it. that is if their intention with this malware was a benevolent one :) but I guess feature iteration in malware that is "supposed to be good" would be tricky

> reports every instance to HIBP

no, that doesn't make sense if its only meow who found it. And since there is no way to know that, it does not make sense to mail a copy to hibp

Oh, they'll have to say something when they suddenly stop doing business until a backup can get pulled, and the new db instances actually secured before putting them up again.

Even a bland 'we lost parts of our data and we will have to start recovery processes. please stand by' is a signal.

Ideally they'd report it so that password managers could warn everyone, but with just the database URI there isn't necessarily any obvious way to know what domain or business its associated with.

Doesn't really matter, as long as the credential is exposed, users can be warned. No matter where it came from.

If the attacker can write to the DB, then they can add entries to every table with the string "Hey your database is unsecured!"

> Somehow I feel good about this.

For me, it's not exactly "good." But I am more upset with the database owners than I am with the kitties. Don't leave the barn door open, or this (or worse) will happen to you, and happen again. If they were instead exfiltrating and selling the data, the equation would change. I'm not saying the cats are doing good, but I do say that the "responsible adults" did the greatest harm by not cat-proofing their databases that contain PII.

I'm ambivalent about this action in most cases, but in some specific cases there can be a clear reason to have an exposed database: namely when the database is a guest-accessible, read-only repository of public data, i.e. the self-hosted equivalent of publishing a Google BigQuery dataset.

As someone who runs such a "public-access data library" myself, I would be slightly annoyed if someone came along and burned it down, just because it has an unpatched vulnerability.

...but if it got deleted because I left default admin creds on it, though, that'd be my own fault.

Databases that are read only would be unaffected by this attack.

Read-only in practice, not inherently read-only in the way that e.g. CD-ROM is. Such systems still need to have their otherwise-static dataset updated "online" by an ETL pipeline agent-user. Which often means, in the DBMSes with less fine-grained security models, that such users need to have full DML (and even DDL) capabilities, rather than only insert capability.

This attack was only possible on databases with unsecured or weakly secured read-write access.

Who says it's consumer data? It can be a personal project, a blog, etc.

Just because it's not secure doesn't mean you should delete the data, because where does such reasoning end?

Reminds me of the super meat boy web version with database creds in client. Dev knew, but just did a quick implementation. Hacker wanted to prove his point and ruined it for everybody. Making a secure version was not worth the effort, so now because of this prick nobody could enjoy it.

This also affected people who use software for things other than businesses. People with IoT apps for their home, researchers, etc.

Our field is vast and there is a large variance in people just using the basics of CS and those who keep up with standards and best practices, etc.

Your statement is basically akin to someone saying that it’s fine for people to get robbed if they went out with their wallet; or worse.. killed.

Yeah. I don't care if some big business loses their Elasticsearch data and their site stops working until they get it secured and re-hydrated with data from their relational database. Good, they learned a lesson.

But I would feel bad if someone's small business had to shut down or lose a bunch of money because they lost all their customer data. I'd feel bad if someone lost all the data they'd been using for a personal project. If they didn't have backups and proper security, shame on them, but ideally they would be contacted and given advice. Ideally, their data would only be deleted if the effect would be minimal.

On the other hand, if this is something that happens consistently -- all unsecured databases get deleted immediately -- maybe the data would be stolen less and everyone would have to learn their lesson early...

> But I would feel bad if someone's small business had to shut down or lose a bunch of money because they lost all their customer data.

Don't. When businesses of any size cut corners and provide services they aren't qualified to provide, it gives them an advantage compared to businesses that try to do it properly. They make more money or charge less and can often out compete competent owners. They'll also be the first ones to brag about how brilliant they are at business (in my experience).

Small businesses are no exception. Delete away IMO.

Said small businesses might have no idea their data wasn’t secure. That would be on whoever developed their technology, not necessarily the business. Not all small businesses with customer or sales data is a technology company.

Good point. You're right. I was really only thinking about tech companies that are doing their own deployments, but I guess there's plenty of room for collateral damage where people don't deserve it.

Seems like a lost opportunity to have a more nuanced position here. And when you can't think of a single case that could make you feel bad for someone, it's usually a sign that you don't have one.

I’d feel bad if someone’s hobby project was deleted. Small businesses losing customer data is only slightly more sympathetic than people getting sick because they didn’t think the health code applied to them.

If you collect it, you need to be responsible for keeping it safe. Anything affected by this is already exposed and has to be assumed to have been breached.

What if it was a small business's inventory data rather than customer data?

Seems to me, there are a lot of things businesses could store in a database which don't necessarily need to be private, or which at worst won't harm anyone other than the database creator if exposed.

That’s why I was specific about customer data: it’s basically a question of who’s harmed - if the cost is borne by the person cutting corners it’s more of a self-correcting problem.

It's not a matter of "cutting corners." Think of all of the small businesses that recently moved online due to store closures. These businesses simply do not have the budget required to create something comparable to, say, Best Buy's e-commerce. Sure, Shopify might come close, but how do you think Mom and Pop will find and create an e-commerce solution?

That’s the very definition of cutting corners. If they aren’t confident of their ability to operate safely they need to either hire a professional or go without - just as not wanting to pay a plumber doesn’t exempt you from meeting the health code or saving on accountants will be a get out of jail free card when you get audited.

If it sounds like I’m unsympathetic, yes, that’s true. Playing around with building your own database is a good learning experience but that changes once you expose other people to your mistakes. I’ve also dealt with a few small businesses and the people trying to run a business like this are always trying to save a buck - they’re the same ones who stiff contractors, avoid paying overtime, do their own taxes creatively, etc. If you have a successful business, you’ll drop a few bucks on Shopify, Wix, etc. to focus on the business rather than a distraction.

Think how easy it is to take advantage of grandma for "tech support," whether it be from India or at a seedy computer repair shop. It wouldn't surprise me to hear that the majority of small business owners have never heard of Shopify or Wix, as they are more likely to turn to someone they trust, whether that be a "tech-literate" cousin or a local service. Keep in mind that many of these businesses didn't even have websites a few months ago, let alone e-commerce solutions. Not everyone lives in SV or NYC and is perennially exposed to their ads.

I agree that these businesses shouldn't be doing this by themselves, but the tech industry shares some culpability. It should be ingrained in people's heads to think of security first. Most people outside the SV bubble are still using [SO or pet's name]123 as their password. I go to a university in NYC. I've tried to convince several (college) friends to use password managers to no avail. This isn't just a problem endemic in old people. Someone needs to "mainstream" good security. A good start would come from, say, Apple, by including security keys with new iPhones, as much of a pipe dream as that might be.

Personally I hope this becomes so common place that it doesnt even make the news.

Like the old days with slammer or codered

It took 13 seconds for a freshly installed windows box to be owned when it was put online. Let those days return.

> Yeah, I don't care if a big chain restaurant is closed down for having too poor hygiene. But I would feel bad if someone's small restaurant had to shut down because the cook doesn't bother to wash his hands at work.

If you are holding other people's data for them, you have a responsibility to do your best to keep the data safe. If you don't know how to do that and don't have time to learn, you can hire someone who is more knowledgeable.

And what about the responsibility to not destroy someone's property?

Do you have the same opinion about shoplifters walking away with merchandise? Would your argument be that there should be armed guards and searches in every retail store? Isn't it reasonable that a thief be criticized and penalized for their actions even if the theft was "easy" to commit and is it OK to blame the victim for not being prepared?

Agree with nkrisc -- this is like, if I contracted with a storage company, and then my stuff was vandalized because the company's "secure storage location" was an unlocked box out on the sidewalk. Obviously the vandal is directly to blame, but it's also absolutely negligence from the company.

I'm sympathetic for the people who were only storing their own data, but not for companies that failed to safeguard their customers' data. If I borrow stuff from friends, I take better care of it than if it were mine. I hold companies to the same standard.

I'm not trying to disregard the negligence concern but I am trying to ensure that the perpetrator is also called out. Several of the top rated comments on this article are praising the perpetrator.

You will notice that in my post I'm not defending the people behind the meow attacks. I agree, they are very much in the wrong.

But being careless with other people's data is also wrong and we should not feel bad for companies whose negligent practices backfire on them. That is what I was trying to highlight with my analogy.

Like bacteria, there will always be bad actors trying to exploit poor security. If not these attackers, then someone else. That is why we have security measures.

The people we should feel bad for are the individual customers affected.

Ps also, there is a big difference between being careless with your own property (your analogy) and someone else's property/data/wellbeing (my analogy and the case at hand).

But it's my personal and sensitive data that they are poor stewards of, not their property.

I agree but I don't think that changes my point that the person who destroys the data has more culpability than the storage service in the destruction of the data.

There tends to be a pass given to people destroying data and I don't think that is right.

I agree, but I think it's beside the point.

As engineers we have to assume that there is always someone out there looking to break into our systems. We don't get to blame them for our failure to secure our systems.

For us to be angry at the hackers is as fruitless as it would be for the unhygienic cook to be angry at the bacteria.

Why are you making the assumption that I'm making the point "as an engineer" as opposed to just a citizen who thinks it is reasonable to expect people not do destroy something that doesn't belong to them?

Your analogy about bacteria doesn't make any sense, we don't expect the bacteria to be actively seeking out unhygienic cooks. If you want to use your analogy it would be like having someone shake the cook's hand in order to put a mild irritant on their hands so that when they prepare food without washing or gloving their hands the irritant is spread to the food, thus highlighting the fact that the chef wasn't following good hygiene. Would you expect that behavior to be excused? Would you be OK with that if you were the one throwing up?

You're presumably an engineer, I'm an engineer, this is an engineering forum. That is why I may have "assumed you made the point as an engineer".

It sounds as if you think I'm defending the attackers. I'm not. I'm pointing out that the presence of malicious actors is a fact of life on the Internet, like it or not.

I'm not going to take my analogy further. I think it's reasonably clear what I meant.

I'm not sure wiping out data from these unsecured databases is the answer, but even for amateur installations which have data of no relevance, the database could be used for nefarious things or the machine itself it runs on could be taken over and used for things such as DDOS attacks.

In that sense, receiving a strong notification that your compute is available to anyone and you should secure it is a good thing.

This is more akin to a person knowing the basics of driving a car but not which side of the road to use or what to do at a traffic light. They are a danger to themselves and others, the others in this case being the users of whatever services the unsecured databases provide.

My sympathy for people learning the basics of our field and missing a few points stops when others are harmed.

Although the parent's analogy is arguably flawed, there's a very good point in the fact that there are users who are not involved in the implementation of the service - "People with IoT apps for their home". They're not drivers, to follow the driving analogy.

It's unrealistic to expect that the population at large starts to pay a significant attention, in particular because the services/gadgets are a black box. How does one know if a device is safe? A layman surely can't; even somebody who's "just a dev" likely can't.

Given the large-scale nature, probably some form of regulation would be the most realistic mitigation. Following the analogy, such users are taxi clients, and for similar reasons, taxis are regulated.

With that in mind, certainly the engineering side of the equation should be held accountable. But it seems that the market is not punishing it at all.

Yup. My point is some people might not even know that their database is accessible from the web lol. It’s pretty easy to follow a tutorial or get something OOTB that’s not secure, so we shouldn’t be saying we’re glad this happened. Even if it’s big businesses, what if said businesses were storing important data such as health records?

I think the learn by failing is a good mentality but was hoping we can be mindful of the fact that this harms more than just the “big bad man”

Edit: Addendum for a more thoughtful discussion, it would be great if these databases and tools provided some default security OOTB requiring no configuration whatsoever. Example: rather than creating user and password with root, is rather have some CMS site generate a random one!

Legislation is just so far behind. User data is useful, but there should be requirements before you can just accumulate it. Cars are useful too but require a licence and insurance to drive.

> Given the large-scale nature, probably some form of regulation would be the most realistic mitigation.

Rather than regulation, how about trademark-protected certification? I.e., similar to what Underwriter Laboratories ("UL") does for consumer electrical products in the U.S.?

Except rather than the government requiring certification by UL or similar, organizations could simply decide for themselves whether or not to use uncertified products. And perhaps insurance companies could price certification status into relevant policies.

IoT is unlikely to be affected, unless the device goes out of its way to expose its database via upnp

This is my thought - why would an IoT device expose a database publicly? And if so, shouldn't the companies producing those devices not be following such bad practices? Maybe the consumer who bought such a device should go to the manufacturer and complain about being sold an inherently insecure device.

Just because its offering some useful service doesn't indemnify the ownership from the bad methods they use to deliver the service.

Exposing your database to the internet with default creds is not "standards and best practices" - its highly negligent, and if you are taking people's money for such a service, I have no pity for you.

>Your statement is basically akin to someone saying that it’s fine for people to get robbed if they went out with their wallet; or worse.. killed.

Uhh no? The analogy would be that there's some benefit that comes from someone's wallet being destroyed, instead of stolen.

I’d say it’s closer to leaving your wallet on the street. If you don’t care to protect it you should assume someone will fuck with it.

If you can't or don't know how to secure it, it shouldn't be online.

My argument is more akin to a child learning not to leave their bike unattended on a city street corner overnight. I can come by pick up the bike, and tell you the dangers, but there's only one real way to learn.

And clearly my opinion isn't even close to comparison with somebody being killed in a robbery.

Just putting a password on a database is more than a 'standard', it's truly common sense. Really, even a beginner should think of this. Otherwise they shouldn't be messing with this stuff.

And if they do get 'meowed', lesson well deserved.

Would you send or let people venture out into the Wild West in its heyday unprepared and unequipped?

Why aren't we applying this same logic to CS topics? It's a vast world out there and much of it's out to get you. Be prepared or die.

That's not a good argument, inexperience does not excuse exposing user data.

Would you feel the same way if someone burned your house down if you left the door unlocked? Would you support the idea of people walking through a neighborhood and checking every door in a similar way? Does your opinion change if it happened in a business district?

I think it is fine to argue that doors should be locked but that doesn't mean that a crime hasn't been committed when someone takes advantage of a situation.

The first crime committed was leaving people's data out in the open.

If someone had a list of names/birthdays/SSNs posted on their door, I'm not too unhappy if someone blacks out every line with the word 'meow.'

Not sure why you are focusing on the PII scenario. The original report seems to say it is just "unsecured databases" and not databases that have PII information posted.

You are also making an subtle assumption that the service is being administered by a 3rd party. Could be that the service is being administered by the owner of the data.

In any case it is still wrong to delete the data.

The folks hit didn't have backups (if they did, well anyone can restore them), nor did they secure their db. One is forgivable. Both together get no sympathy from me. Rather disgust that some of them had PII from customers that trusted them.

More justification that this is an appropriate way to teach people a lesson. You don't seem to care at all what the impact might be on those affected. You are in affect encouraging the criminal behavior because the ends justify the means, apparently.

While I understand the concern that organizations aren't taking proper care to protect their data I think legitimizing vigilante punishment for those mistakes is a very problematic stance.

I'm a huge thought-criminal. A threat to the state!

It's literally any unsecured database, not just databases containing PII.

What if you just have a toy database for a toy project on the public internet and some jerk just deletes it to "teach you a lesson"? It's like, gee, thanks...

Except that I didn’t leave the doors open. Someone I trusted with the keys, left them in their safe. Unlocked. So I rather have their whole place burned down and MY keys melted at the same time.

You are suggesting that it was just "keys" but that isn't the case here. You don't know what type of data is being destroyed.

A better example might be a storage unit service that left the front gate unlocked. If someone torches the place to illustrate that they need better security would you be comfortable with that? Isn't there a better approach that we should encourage or is OK to encourage people to destroy things that aren't protected to teach people "lessons"?

Maybe. However, if this was my diary or photoalbum, bank statements, medical reports or anything of that sort I’d rather have them destroyed than knowing that they may have been copied... The lesson is not for the people, it’s for the companies that take shortcuts to save money. It for the MBA’s that think things don’t have to be properly engineered.

So you are rationalizing a crime because it teaches companies a lesson? That is a crazy rejection of the rule of law. Would you be comfortable in applying that logic to all crimes?

I'm not gp, but let's take a step back for a sec.

(I've mostly lived in the northeastern US)

I live in a small (~20k population) rural technically-city (but... it's a town) where crime is not much of an issue; my car sits unlocked in my driveway and I seldom lock my house -- when I do, it's almost always when I'm at home (alone) -- it's about a feeling of security, not any real risk of a break-in. I've lived this way in this town for many years and have never experienced a robbery. I think it's pretty low risk, not irresponsible.

I've also lived in a larger city. There, I absolutely locked my doors. And I've traveled to tourist-y locations known for pickpockets, and kept an even closer watch on my belongings.

The internet is two orders of magnitude larger than the world's largest city and policing it is exceptionally difficult, since it spans national borders. There will be crime.

I wish this weren't the case. I much prefer living in a safe place where I don't have to worry about locking my doors when I go out. But when crime is common, it's negligent not to protect against it.

I agree with all that and I also don't want to let the perpetrator off the hook. In your example, doesn't matter if the crime happens in a place where it is uncommon or not, it is still a crime and we shouldn't excuse the perpetrator by suggesting that the victim needed to be taught a lesson.

I think the major difference is that losing my house along with all my belongings is much worse than losing just some of my belongings. Also data being exposed publicly can be used nefariously by multiple parties, so is likely worse in most scenarios compared to just outright deletion of the data

Ok, but losing "just some of your belongings" is bad also, right? When thinking about the culpability of the person deleting the data or storing the data, we have to start from the assumption that the owner of the data values it.

Whatever analysis you want to put on the situation I don't think it is reasonable to start with the idea that some of the data might not be that valuable.

Either the data is something public (name, address, etc) in which case, whatever.

Or it's data that was gathered (in line of business, for example) and its destruction is anywhere from more secure to an inconvenience.

Or it's data that was aggregated beyond legitimate use (hey, FAANG) and by all means, tear it the hell up and throw it away.

Why do you feel it is important to characterize the nature of the data? The unauthorized deletion is wrong regardless of the nature of the data.

I think I'm having a somewhat uncharacteristic relativist thought... I feel that the indiscriminate and nearly unregulated collection of any data any company feels like grabbing hold of _should_ be countered.

I feel like the wrongness of deleting unsecured data is a pittance compared to the crapload of other wrongs that have been visited upon us 'products' by failures of diligence or desire or consequence.

I would very much like to hear, if it turns out to be so, that the operators of 'meow' are selectively targeting more likely corporate data, especially with customer/user data, but in the end I'm still ok with the idea of burn it all and let the DB vendors and IT staff who let their asses hang out explain why security was so low on their priority lists.

And yes, I'll take some potential difficulties in my own life due to unexpected deletion complications in the process. I'm not asking anyone else to accept anything I'm not going to be okay with myself.

...wrong regardless...

That obviously isn't true. Some data shouldn't exist: CP. Some data can exist, but it's backed-up so well that deletion is never a problem. For example, I'm not going to forget my birth date any time soon! In fact, very little of the information that businesses have about me needs preservation. I remember it all, and if I decide the business still deserves it I can give it to them again.

It is of course possible that some of this data didn't need to be kept private, and therefore shouldn't have been deleted. Maybe some medical researchers had compiled the data they needed to formulate the ultimate cure to COVID-19? (I hope they had anonymized all the patient data!) Until those researchers come forward to lament humanity's loss, I'll just assume that all the "victims" who don't want to go into too much detail about the "lost" data were playing fast and loose with their customers' private information.

So your argument is that any random person is in a position to evaluate whether someone else's "data shouldn't exist" and take unilateral action to delete it? And are you suggesting that in this particular case the person launching this attack is taking time to evaluate the nature of the data before taking action?

> I'll just assume that all the "victims" who don't want to go into too much detail about the "lost" data were playing fast and loose with their customers' private information.

Why the scare quotes? It takes some serious amount of chutzpah to advocate that it is a reasonable assumption to assume the data wasn't important and to use the lack of public complaint as evidence that the data wasn't really important. Why do you even think it was "customer" data?

I didn't just invent this idea that businesses are careless with data their customers would prefer to be kept private. Basically every breach we ever hear about features this prominently. Somehow we've created an economy in which there exists a vast asymmetry between corporations who pad their books a few percentage points by abusing their position and the humans who suffer such abuses. The fact that the publicity of small bits of data about a human can cause that human massive harms is itself a contingent creation of our screwed-up system, which benefits the giant companies whose lobbyists write the laws. It's as if someone decided we should all live under the "protect your True Name at all costs" system from the Earthsea novels, without giving any of us any way to do that.

There's very little a customer can do to determine how or even whether her confidential data is protected. Even if she had this knowledge, in many cases she can't just decide to do business elsewhere. In many cases she was never a customer in the first place! In this context, an open database is like a shoddily constructed tall building that will collapse at the first stiff breeze. It shouldn't exist, and anyone who destroys it upon discovering it is doing humanity a service. Even if the building's owners had somehow kept the general public out (which you'd like us to assume), those owners themselves increased their danger with every bit of data added. Now, since the building has been destroyed, its owners and occupants are no longer in steadily increasing danger.

You seem entirely focused on PII concerns and arguing as if the only organizations affected by this incident are "giant companies". That doesn't seem to be the case. I haven't seen any suggestion that this incident is focused on that type of data.

As much as I agree with all the concerns posted here about how data should be protected better I don't think it is necessary to excuse and legitimize the unauthorized access along the way.

Wealthy interests built the system, but they're not the only abusive actors within it. It would not surprise if smaller firms completely failed to protect the data of other parties more often than larger firms did so. The best way for database operators to prevent unauthorized access and deletion is to secure their databases in some way. The best way for anyone else to prevent abusive access is to delete unsecured databases. Working together, this problem will be solved eventually.

I don't think the parent suggests it exonerates the hackers. Just that the clients are better off.

Better off? The idea that victims deserve to be victimized because they didn't take enough care is trotted out every time a security issue comes up on HN.

Thr victims are the unaware customers who's data has been stolen because the company wasn't providing security.

If a business left the store open with the customers credit cards details on display. Anyone passing by can go in and copy that info. Someone sees this and burns the exposed records. Perhaps they helped the victim.

Remember no one burned the store down or the table holding the records. They burned only the exposed records.

You don't know who was the storage vendor and who's data was being deleted and you have no idea what that data represents or what the consequences are of having to restore it.

You are making several unfounded assumptions.

No one knows more information than the article presents.

When you state that victims exist or that the data being deleted is important you are also making unfounded assumptions.

You can't have it both ways.

I think it is entirely reasonable to start with the presumption that people have a right to their data and to their property, that it is valuable to them.

If a site/service has a right to allow a person to delete data. The machine can be setup however they like. These are not hacked databases. The system said welcome what do you want to do? You can read everything or delete everything or add anything.

So they did.

> These are not hacked databases.

Yes they are. The method of the hack was 'simple' to you, but that doesn't mean it's just magically not a hack any more. These are hacked databases.

> The system said welcome what do you want to do? You can read everything or delete everything or add anything.

I don't understand this. Are you suggesting that the attackers were greeted by the database with an English-language legal directive of what legal permissions they had in the database? What do you mean by this statement? Surely the databases said no such thing.

If you're implying that a private door with no lock is not private but actually shared property that can be destroyed or added to in any way, then I think you're wrong. None of this comment makes sense to me. An unsecured database holding private data, or an unlocked door to a private business or building, is not an open legal invitation for vandalism.

If you attempt to connect to a database the database will greet you. It can be configured to ask for a login. It can be configured to have no login. If it doesn't have a login and gives you a welcome prompt it's not called hacking. In order to hack something it needed to be secured to start with.

Databases do greet users in mostly english. Need help? Type help. On the list of things the system allows deleting data appeared to be one.

If you knock on a door and the door opens and says welcome what do you want to do (delete data, read data) and you pick delete it doesn't mean it's illegal vandalism.

> It can be configured to have no login. If it doesn't have a login and gives you a welcome prompt it's not called hacking. In order to hack something it needed to be secured to start with.

I very strongly disagree with this. Can you cite somewhere that unauthorized database access is not hacking if there is no password? To me and I think the law that is definitely illegal and hacking.

> If you knock on a door and the door opens and says welcome what do you want to do (delete data, read data) and you pick delete it doesn't mean it's illegal vandalism.

Yes it does! If you don’t have authorized access then that database isn’t yours and entering it is illegal.

These aren't victims; they were harmed through their own gross negligence or the gross negligence of the developer they employed.

They aren't victims? If you forget to lock your car door and it is stolen or something inside it is stolen are you also not a victim by your logic?

I don't have a feeling one way or the other, but I see where you're coming from and I think there's an interesting aspect that many of the folks here seem to be missing.

Were this sort of attack to become part of the "noise" of the internet (much as the continual bombarding of my SSH ports) then peoples databases would get deleted _before_ they contain any meaningful amount of data.

So in practice this sort of gross vandalism is limited to the appearance of such an attack, but not ongoing.

I had this the other day building OS images, which accidentally left the system a passwordless login. Within less than a few hours it was (presumably) spewing mail or doing awful things -- long before anything went anywhere near production data or any kind of trust.

> [Article] They could be the work of a vigilante trying to give administrators a hard lesson in security by raining destruction on unsecured data.

It could be a person attempting to prevent the data from falling into the wrong hands. Problem is: once it's deleted, you have no idea whether your data was stolen and shared. A better option would be to first send a copy to Have I Been Pwned.

I wholeheartedly agree. I cannot think of a scenario where a company exposes my data and I would not want it to be deleted ASAP. The only thing is that such companies might not be able anymore (if data was not backed up) to email me about a “breach”.


Any entity this irresponsible shouldn’t hold data.

Could be both


Somehow I feel good about this.

Frankly anyone who is still using MongoDB is professionally negligent and this was if not deserved then certainly inevitable.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact