New ‘Meow’ attack has deleted almost 4k unsecured databases
bleepingcomputer.com
bleepingcomputer.com
https://stackoverflow.com/questions/63067062/elastic-search-...
Edit: The person raising that question is working for Atlassian (Jira), looks like Atlassian got their database deleted lol
> 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.
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).
> 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.
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!
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.
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.
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.
> An interesting theory as to why the attacker used the term "meow" is because cats like to drop (or knock) items from tables.
[0] https://www.elastic.co/guide/en/elasticsearch/reference/curr...
FTA:
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.
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 entirely agree the vendors are (partially) to blame here.
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"...
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!!!")
Don't make excuses for their shitty business practices.
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.
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.
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!
- 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.
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/
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.
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.
Anything that is insecure by default in 2020 should be killed off IMO.
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.
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.
The fact it's not, is why we're seeing major attacks/leaks/etc almost every single day now.
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.
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.
reads TFA again Wait, one of the victims is a VPN provider???
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.
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.
At least google "securing X" before just pumping data in.
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.
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.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=redis+remot...
Ended up deleting the server.
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.
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.
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.
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.
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.
Deleting exposed databases is genious, there need to be real repercussions for companies if they leak user data.
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.
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.
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.
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.
> 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
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
Even a bland 'we lost parts of our data and we will have to start recovery processes. please stand by' is a signal.
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.
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.
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.
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.
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...
My sympathy for people learning the basics of our field and missing a few points stops when others are harmed.
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.
Uhh no? The analogy would be that there's some benefit that comes from someone's wallet being destroyed, instead of stolen.
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.
And if they do get 'meowed', lesson well deserved.
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.
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.
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.'
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.
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.
Any entity this irresponsible shouldn’t hold data.
Frankly anyone who is still using MongoDB is professionally negligent and this was if not deserved then certainly inevitable.
I'd also note that not all DBs contain other people's data. Those have no moral concerns with bring public. There is a risk that someone will destroy it, but I'd say that's the same risk taken with public art or something. Yes it's public; yes someone can destroy it; yes it's illegal for someone to destroy it (even though it's public); no, the fact that it's public is not illegal.
It is illegal in the USA. And is easily an arguable civil case as well. The problem is identifying the perportrator.
Organizations are only way to hold poor actors accountable. Bad PR and going out of business cause data critical to operations has all been deleted are strong incentives. Unfortunately businesses typically lobby for harsh laws, tyrancial surveillance rather than the expensive and difficult process of improving their operational security.
I assume other countries have similar laws.
That said, enforcing it is a different matter.
They are based on disasters, but at least we try not to repeat the same ones.
One of the things that drew me to software was the idea that you could fix a problem once and for all and then just keep reusing the solution for ever and ever. I don't think I'd have the heart to go back and tell myself what a stupid notion that turns out to be.
Sort yerselves out.
2) Even if it were, and my twenty-something assistant left my shop door open at night consistently, to me, the question of the legality of the resulting damage would be rather secondary.
Is this attack literally "attempt access each database listed on shodan.io and destroy it if that works"?
I might be missing some major aspect (I certainly hope so), but isn't this like wondering why all those fireworks that people keep storing on the streets were eventually set off by some kid with a mask? Why isn't the question "why didn't this happen sooner"?
For example, this was from the same news website a few years ago:
https://www.bleepingcomputer.com/news/security/massive-wave-...
I've also written about it many times:
https://blog.shodan.io/its-the-data-stupid/
https://blog.shodan.io/its-still-the-data-stupid/
https://blog.shodan.io/the-hdfs-juggernaut/
https://blog.shodan.io/elastic-data-exposure-grows-to-3-2-pb...
Would especially be useful if you were tinkering with firewall/security settings and accidentally opened something up.
Disclaimer: I'm the founder of Shodan.
Also just curious, what’s your annual revenue like?
Edit: I also do this as a service, have for years, and hammer my own system monthly.
But seriously, these guys are doing us a favour. You can bet the affected companies will not expose customer data again.
I hope so, but I seriously doubt that. Having open databases is extreme incompetency.
A Department of Botnet-Suseptible IoT Device Bricking would be useful in the same way.
Way back in the early 2000s I was a young mid level developer and we had a SQL Server backed solution. There was a wide spread attack on Sql Server installations that didn’t change the default blank SA password. We were one of the companies that didn’t.
But, even then I knew not to have a publicly accessible database server. We just didn’t give the server a public IP address. Nothing fancy. We weren’t affected but I immediately changed the password.
Fast forward to 2018. The company I worked for was just starting to ramp up an in-house development staff led by a new CTO. Everything had been outsourced to a foreign agency. They had a publicly accessible ElasticSearch cluster. I wasn’t on the team responsible for it, but I know that the architect on the team knew better. Even though he didn’t setup the original cluster, he knew it was insecure and just didn’t prioritize recreating it inside our VPC.
Of course we got hacked and someone deleted everything in it. Then they decided to go ahead and recreate it inside the VPC. Luckily we didn’t use ES as a primary store and we were just offline all day while we ran the process to repopulate the cluster from our Mysql database.
Why do people keep making the same mistake? I was definitely not any world class software architect at 25 years old, but even I knew to be cautious about giving servers public IP addresses unnecessarily.
You know a “private IP address” isn’t one that’s not known it’s one that not routable over the public internet.
RFC 1918 was written in 1993
Because there are always new developers showing up that haven't been taught. (Eternal September if you will)
The real solution would be:
1. We are past the point were our practice needs professional licensure. We need standards, a governing body, and ethics.
2. Those above items need to be taught to new developers. How long has security been an after thought to CS degree programs? I know I never touched it in an academic setting. We didn't even have a class that covered it. You wanted to learn about it you had to seek it out.
3. Vendors to do the right thing and stop offering default passwords. That isn't going to happen, so we have to force them to, either trough legislation or through other means.
The good that comes from destroying the DB is:
a) the data is no longer exposed to the Internet, where more malicious actors could take it, affecting the customers of the incompetent company
b) ignoring it stops being a viable option - leaking your customer's data all over the place often doesn't have sufficiently obvious and severe consequences for the company doing the leaking to discourage it. Disruption that breaks production will get their attention, and they likely will secure their database in the future.
(No moral or legal judgement regarding this action, just answering the "what good comes of it" question.)
Edit: Also, someone commented further below on the difficulty of doing it the right way - it's hard to contact the companies, and it's even harder to get them to actually listen and fix it instead of ignoring it or trying to "shoot the messenger". This approach may be wrong and/or illegal, but it it much likely to actually draw the attention of the right people, and prevent them from simply ignoring the problem.
The companies running those open databases aren't just victims; they're also perpetrators of privacy violations. In many cases, they're even collecting data for a purpose that the data subject receives no benefit from.
For completeness, would you mind answering, "what bad comes of it?"
I am pretty salty since as a sysadmin, I have been getting 'just pipe it to su bash' and 'i need allow any any' and 'bro I need chmod 777 on this directory and all its children' and 'bro this service account has to be a domain admin' from developers my entire professional career. Everything that there is to say has already been said and I am not really sure what to do about it. Nobody is out there peddling these cool fixes as truth and yet they seem to have a cult all the same.
What can we do to make this common knowledge? This needs to be on the same level as washing your hands and not accepting candy from strangers, yet every week we see a new data breach that boils down to 'somebody used the rights as they were designed'.
To whoever is doing that: you are doing god's work, please keep it up.
Also, as a bit of an aside, the relationship between "export credits" and "query credits," and the export system and API of Shodan, are extremely confusing and just a bad bit of product design. Each one seems to be capable of things the other isn't, but they're priced on totally different systems.
But really it's mostly just a matter of motivation, I think. Pulling even just thousands of entries from Shodan, writing some software to use them, and then running it in a reasonably deniable way, takes effort and is pretty slow (why we see this going for multiple days). It's not a huge amount of effort but it's enough that "script kiddie" types don't really seem to do it, you need to be motivated and spend the time on it.
Contrary to security urban legend it seems like the number of people who are highly motivated to purely cause damage is not actually that large, people only put in the time if they can figure out a way to gain from it... and just deleting data doesn't really achieve that. You've got to figure out a way to hold it for ransom and/or collect and leverage sensitive data. We've seen both happening on various scales with this kind of unsecured database and we'll probably see more of both as we go forward... but keep in mind that in the ransomware game, encrypting computers is both easier (established off-the-shelf ransomware can be purchased) and probably shows higher returns, so the "professionals" aren't spending a lot of time messing around with exposed databases.
https://blog.shodan.io/its-the-data-stupid/
We've also sent the raw data to various database vendors for free but even for them it's difficult to reach out to customers to get it fixed. And then there's always the worry that you'll get shot as the messenger of bad news. We've had a lot more success in getting things taken offline when we already have some relationship with the organization or at least a mutual customer.
In the past, older versions of MongoDB were more public than newer versions but that isn't the case anymore based on what we're seeing right now:
https://beta.shodan.io/search/facet?query=product%3Amongodb&...
And in terms of Shodan, we crawl 24/7 (i.e. not waves) and update the search engine as the data is collected with a small delay (<1 hour) so anybody that gets real-time notifications (https://monitor.shodan.io) for their networks will see it before it shows up on the search index.
And this issue doesn't just affect MongoDB - imo since the "webscale" days it's been a favorite to knock on but the public exposure of data happens across many technologies. Here's a comparison with a few others:
https://blog.shodan.io/elastic-data-exposure-grows-to-3-2-pb...
E.g. A database That intentionally removes itself if the default password/an insecure password is used, with an easy-to-follow guide in error log on how to properly configure it.
All software should work like that.
Note I don't blame anyone, it was just bound to happen.
You access it because it's publicly available...
$ shodan count product:Elastic org:Azure
This entire website is powered by a free API key: https://exposure.shodan.io
Crickets AFAICT: https://twitter.com/kimchy
That's more or less the best you can do without unreasonable effort, and there's no guarantee the database's owners will ever see the extra database unless you also destroy stuff on the way to make them pay attention...
That person was very grateful for the heads up, but the other three were SOL.
So one wonders how many people will be positively effected by this.
> “In this server, all the collected information is anonymous and only be used for analyzing the user’s network performance & problems to improve service quality. So far, no information has been leaked.”
I can't see how you can keep enough info to analyse an individual users service, without keeping logs on their access details (source/target IPs). What BS.
Vigilantes make their own choices, but professionals are judged by their reputation. As I've said elsewhere, I challenge anyone, especially professionals, to tweet "I will delete your data if you don't secure it" and to add it to your resume/CV as a strength.
If, given the frequent and public attention to hacked data, you aren’t thinking about how to make sure your data is safe, there really can’t be any sympathy when you get hit by an attack that relies on zero security applied to your database.
C’mon, do we as an industry really learn NOTHING from all the hacks we’ve lived through ?
If you're hosting your own DB on a cloud provider, connect using a VPC / Heroku's Private Space Peering to keep your database off of the internet.
...and also not enabling a password
Also as a rule of thumb never ever expose anything but port 80 and 443 if hosting a webapp.
If you must expose services other than http/s then be sure to not leak its version, have it secured properly and _always_ up to date. The user running such services should also be a non privileged user, the daemon chrooted, and the OS should have appropriate process and filesystem permissions in place.
Okay, and I prefer being waterboarded over being drawn & quartered. But it doesn't mean I support the practice of waterboarding, since there's another option, namely just not waterboarding in the first place.
This contrarianism is so strange to me. Data not being deleted by a bad actor is preferable to having it deleted, and I would think that would be the main takeaway here, rather than this weird descent into counterfactuals. Where does the impulse come from to bypass the normal answer, treat it like a trick question and go into contrarian mode by measuring it against counterfactuals? I think when you do that you lose sight of the most important thing here, which is the fact that data is being wantonly deleted and that it is bad that this is happening.
How do you know it wasn't?
The ones leaving giant databases unsecured? At least they are being taught an important lesson.
1) the cultural and economic forces driving everything online way before that’s anything like a good idea,
2) companies storing more than they need to,
3) the people who left it unsecured (bigco, tech startups, and anything very sensitive),
4) the people stealing data,
5) the people who left it unsecured (Smaller shops that’ve been made to feel they must be online),
[large gap]
20) someone who simply deletes all the insecure data (assuming they didn’t also steal all of it)
Will it affect MySQL databases accessible from the Internet but secured with a long random password?
That said, if you'd read the article you'd see that so far only unsecured MongoDB, Elasticsearch and Redis installations are being attacked so far.
PS: I don't know exactly what you mean by "Stick an API layer in at the very least with key based auth" because I never used an API before and didn't know I would need something like this.
For example I'd probably trust MySQL or PostgreSQL key validation more than what some random dev has coded in a private repo (more eyes on the code and probably better developers looking at it).
Auth is something that a lot of devs still do not implement properly and even popular libs for it like passport for node and others (including default configs for most JWT libs) have had very bad security issues.
If your minimum permissions map well onto the databases permission model then it's better to not have a layer in between. Proper db permissions and a using TLS/SSH as a transport is probably better.
However, it's highly recommended you never expose such services to the public, or at least limit allowed IP ranges.
Trouble is modern web-development is so dumb they just treat databases as dumb-blackboxes. So hence they end up in situations like this where security is thrown out the window in the name of minimising any obstacles to get data from the database (and no doubt dump it all into a stupid array in the frontend).
This creates a self-perpetuating lore amongst devs that databases are "slow".
But this is largely because they can't be bothered to use the database in the correct manner (correct schema design, sprocs etc. etc.)
And don't get me started on the "portable query" junk ! Sure you can write dumb queries that run on everything from SQLite to Oracle, but its far from being a remotely sensible thing to do.
Rant over. ;)
As for us, we give access via an SSH tunnel, which requires public keys from certain IPs.