
New ‘Meow’ attack has deleted almost 4k unsecured databases - based2
https://www.bleepingcomputer.com/news/security/new-meow-attack-has-deleted-almost-4-000-unsecured-databases/
======
user5994461
Works great. You can already find questions on Stack Overflow from people
getting their database deleted

[https://stackoverflow.com/questions/63067062/elastic-
search-...](https://stackoverflow.com/questions/63067062/elastic-search-
indexes-gets-deleted-frequently)

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

~~~
pramodhs
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 :)

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

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

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

~~~
bigiain
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](http://antirez.com/news/96) ) I do think the
"Securing Redis" section of this page -
[https://redis.io/topics/quickstart](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?)

~~~
dredmorbius
If your assumptions are repearedly demonstrated invalid _they are wrong._

Change them.

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

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

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

~~~
nisa
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://unrouted.io/2017/08/15/docker-firewall/)
[https://github.com/docker/for-
linux/issues/690](https://github.com/docker/for-linux/issues/690)

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

~~~
umvi
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?

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

~~~
rectang
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".

------
nickjj
This reminds me of "crackit"[0] from a few years ago with Redis. A lot of
folks kept their Redis server bound to 0.0.0.0 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](http://antirez.com/news/96)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
cdrini
It's stuff like this that reminds me that the internet is in many ways still
in a loosely regulated, "Wild West" state. This is pretty clearly willful
destruction (I.e. vandalism; [https://legal-
dictionary.thefreedictionary.com/Willful+damag...](https://legal-
dictionary.thefreedictionary.com/Willful+damage)). It's illegal in the real
world, and should be illegal in the digital world. A lot of people are saying
that organizations that had these DBs in public "had it coming", or "now
they'll learn." What's a real world parallel for this? If an organisation is
putting its customers at risk, you can report them. In these cases, companies
with insecure data stores are putting their customers at risk by exposing
their data. Is there anyone you can report them to? Is there any organisation
that will hold them accountable to actually make changes?

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.

~~~
njharman
> It's illegal in the real world, and should be illegal in the digital world

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.

~~~
cdrini
Bad PR works to an extent, but bad PR can be combatted with good PR, not
necessarily with changes. I think an independent regulator would be useful;
one that can testify that a company is following best practices for data, etc.
Although if the regulators don't have any teeth, or if they don't have a clear
benefit for companies to allow a regular, comprehensive, internal audit, it
definitely won't gain any adoption.

------
MauranKilom
The part that confuses me here is that everybody seems to take in stride that
all these public-facing databases are already tracked and indexed. Like, how
does
[https://www.shodan.io/search?query=meow+indices](https://www.shodan.io/search?query=meow+indices)
know all this? What am I missing here?

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"?

~~~
achillean
It has already happened in the past. Repeatedly. There's news coverage about
this at least once a year. And it doesn't require using Shodan as there are
plenty of open-source tools for scanning the Internet nowadays.

For example, this was from the same news website a few years ago:

[https://www.bleepingcomputer.com/news/security/massive-
wave-...](https://www.bleepingcomputer.com/news/security/massive-wave-of-
mongodb-ransom-attacks-makes-26-000-new-victims/)

I've also written about it many times:

[https://blog.shodan.io/its-the-data-stupid/](https://blog.shodan.io/its-the-
data-stupid/)

[https://blog.shodan.io/its-still-the-data-
stupid/](https://blog.shodan.io/its-still-the-data-stupid/)

[https://blog.shodan.io/the-hdfs-juggernaut/](https://blog.shodan.io/the-hdfs-
juggernaut/)

[https://blog.shodan.io/elastic-data-exposure-grows-
to-3-2-pb...](https://blog.shodan.io/elastic-data-exposure-grows-to-3-2-pb/)

~~~
MauranKilom
Jeez, that's a pretty impressive dumpster fire. And it's been going for half a
decade. Kudos for keeping track of it and periodically doing your part in
reminding the world.

------
AznHisoka
Is there an inexpensive service out there that does “mock” attacks if you give
it a bunch of host names and ports? I know it’s something you could create
yourself but would be nice to have a third party try to connect to your
databases and immediately alert you if it was able to gain access.

Would especially be useful if you were tinkering with firewall/security
settings and accidentally opened something up.

~~~
achillean
Shodan Monitor will do it and if you're only keeping track of <= 16 IPs then
you would just need the membership which is a one-time payment of $49 (i.e. no
subscription cost) for a lifetime account upgrade
([https://www.shodan.io/store/member](https://www.shodan.io/store/member)).
You just provide an IP/ network/ domain and we'll notify you if anything
changes or becomes vulnerable. It's basically Google Alerts but for network
ports:

[https://monitor.shodan.io](https://monitor.shodan.io)

Disclaimer: I'm the founder of Shodan.

~~~
AznHisoka
Thanks that’s exactly what I was looking for. I didn’t want an open source DIY
option because I am lazy and just want to plug in Ips and ports.

Also just curious, what’s your annual revenue like?

~~~
achillean
We don't share revenue information but we've seen steady growth for the past
10+ years. All I can say is that Shodan is a profitable, bootstrapped business
with >3.5 million users, 80%+ of Fortune 100 and thousands of universities (we
let them setup monitoring for free for up to 120k IPs).

------
GekkePrutser
It's not necessarily 'deleted', these Script Kitties just replaced some data
with more valuable stuff. You can never have enough meows!

But seriously, these guys are doing us a favour. You can bet the affected
companies will not expose customer data again.

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

~~~
pessimizer
If this keeps happening weekly, they'll fix it. Maybe there should be a
government Agency for Deleting Publicly Exposed Databases that's likely to hit
any that you stand up within a week. Also, make having had a publicly exposed
database deleted something that is in the public record, and highly
prejudicial evidence in civil liability cases.

A Department of Botnet-Suseptible IoT Device Bricking would be useful in the
same way.

------
macleodan
Cats like knocking stuff off tables.

~~~
BossingAround
Brilliant!

------
jb775
If a business or org is careless enough to leave their data exposed, they
deserve to be punished like this. I'd rather have my sensitive data deleted by
hackers than exposed by hackers.

------
scarface74
ELI5:

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.

~~~
lmm
Because you're completely wrong; what you're advocating is nothing more than
security by obscurity. An address is just an address; it tells you where
something is. If you don't have a firewall in place, then any attacker who
cares enough to actually route a packet to your internal servers can access
them. If you do have a firewall in place, then an attacker gains nothing from
knowing the address of a server they can't send any packets to. Private
networks add a huge amount of complexity with its own security holes (they're
easy to scan once you're inside them, a lot of operating systems treat them as
somehow "safer" than the public internet...). They do more harm than good.

~~~
scarface74
You realize you can’t get to a private IP address over the Internet right?
It’s kind of how that whole TCP/IP thing works.

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_

~~~
lmm
> You realize you can’t get to a private IP address over the Internet right?

Of course you can - most end users have private IP addresses these days, yet
they somehow manage to communicate with people on the internet.

A private IP address is of course not routable directly on the Internet. But
routers route, and can certainly route a packet from the public internet to an
RFC 1918 private address. If the routers on the edge of your RFC1918 network
do not have firewalls in place, then they will happily route packets to your
internal servers and you're no better off (against a serious attacker; a
script kiddie might ignore you as too much effort, sure) than if you used
public addresses. If those routers do have firewalls in place, then you're
also no better off than if you used public addresses.

~~~
scarface74
In the case of the attack in question - how would they have initiated a
command to erase the ElasticSearch cluster from the Internet?

Any NAT would be stateful and the communication would have had to be initiated
from the cluster.

Not having a public IP address is not about “obscuring” the IP address. It’s
not like so said why didn’t they have ES listening on a non standard port.

~~~
lmm
> Any NAT would be stateful and the communication would have had to be
> initiated from the cluster.

Only if the router is configured that way - and you don't need NAT to
configure it like that. If the router is open then you just set the
destination address to the address of the server you want it to go to. (As for
getting it to the router you either find a way onto the same segment,
explicitly specify it as a routing hop, use ip-in-ip...).

NAT is not a security mechanism. Often the same device does both, but they are
separate functions.

> Not having a public IP address is not about “obscuring” the IP address. It’s
> not like so said why didn’t they have ES listening on a non standard port.

It's exactly like that!

~~~
scarface74
_Only if the router is configured that way - and you don 't need NAT to
configure it like that. If the router is open then you just set the
destination address to the address of the server you want it to go to. (As for
getting it to the router you either find a way onto the same segment,
explicitly specify it as a routing hop, use ip-in-ip...)._

So if someone purposefully for some reason goes in and configures their router
to map a port to a specific internal IP address to allow internet traffic to
their ES cluster it isn’t secure? Isn’t that kind of stretch? If I posted the
root credentials to my AWS account and turned off MFA that would be insecure
also. Does that also mean I’m depending on “security through obscurity”?

 _It 's exactly like that!_

So am I also “obscuring” my IP address when I am testing an API locally and I
configure it to only listen on 127.0.0.1:3000? Oh no, I just told you my IP
address!

Everything you mentioned could only be done if an inside malicious actor
purposefully made it insecure.

~~~
lmm
> So if someone purposefully for some reason goes in and configures their
> router to map a port to a specific internal IP address to allow internet
> traffic to their ES cluster it isn’t secure?

That's not what I'm talking about. Suppose your router receives a packet whose
destination is that internal IP address. Then it's going to send it there,
unless it's configured to block that traffic.

> So am I also “obscuring” my IP address when I am testing an API locally and
> I configure it to only listen on 127.0.0.1:3000?

No, quite the opposite. Listening only on the loopback interface is a real
security mechanism. Binding to 127.0.0.1 achieves that (though there have been
bugs in the past; binding explicitly to the loopback device is better).

> Oh no, I just told you my IP address!

That's exactly my point! The address doesn't matter, the actual network
routing is what matters. Same thing if you're running an actual airgapped
network: what makes it safe is the fact that it's physically disconnected, not
that you used particular addresses on it.

Real-life example: the UK military's internal servers have real IP addresses
in the 25.0.0.0 range. Probably some of them are insecure. But it doesn't
matter because, even though they have public IP addresses, you have no way to
send packets to those IP addresses, because they've got proper firewalling in
place. It's no different from if they were running a private network - except
that it means they don't have to mess around with NAT, if someone connects
from a VPN they don't have to worry about address collisions.... IPv6 works
the same way.

~~~
scarface74
_That 's not what I'm talking about. Suppose your router receives a packet
whose destination is that internal IP address. Then it's going to send it
there, unless it's configured to block that traffic._

What router is set up by default to route traffic _from_ the internet _to_ a
private IP address unless the traffic initiated from the private IP address?
Someone would have to _purposefully_ configure their router to do it.

Of course someone can purposefully configure an insecure system.

~~~
lmm
Any router designed for professional environments won't second-guess your
networking setup. Either it will route everything by default or it will deny
everything by default and route only those routes you've specifically added,
but either way it's not going to do anything differently just because one side
or the other is an RFC1918 private address.

~~~
scarface74
I understand that. But, we are talking about defaults. The reason the exploits
that this submission is talking about took place is because too many people
didn’t change the defaults.

Assuming people took the sensible leap that private resources equal private IP
address, they are not going to then go out of their way to configure their
router to route their private resources.

As far as “route everything” how is it going to know _how_ to route from a
public IP address to your ES server unless you specifically tell it?

I’m sure no one who got hacked went out of their way to configure their router
to make their ES cluster publicly accessible.

~~~
lmm
> Assuming people took the sensible leap that private resources equal private
> IP address, they are not going to then go out of their way to configure
> their router to route their private resources.

That works until you have a legitimate need to expose a few of those private
IP addresses publicly (which is bound to happen sooner or later). It's a bad
idea to rely on the same thing to carry two subtly different meanings -
especially when one of them is security-critical.

> As far as “route everything” how is it going to know how to route from a
> public IP address to your ES server unless you specifically tell it?

The router knows how to reach the ES server (it has to be able to send packets
to that server if it's providing that server's connection to the internet). So
if someone on the outside does `route add <ES server> via <router>` (or, these
days, slightly more sophisticated alternatives) then they have access to the
ES server same as if it was just on the internet. A few years back this was a
big source of vulnerabilities - organisations assumed that their servers were
safe because they didn't have public addresses, but nothing was actually
stopping people sending packets to those servers if they figured out (or
guessed) what the addresses were.

------
davidbrennerjr
I can't believe people are victim blaming the db admins for not knowing about
vulnerability. What good comes of destroying the db instead of talking about
the vulnerability to the open source projects? Coincidentally shodan; that
I've never heard of.

~~~
tgsovlerkhgsel
There's a difference between a vulnerability, and a common misconfiguration
that usually comes from a "make it work first, security later" mindset.

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.

~~~
heretoo
So, you've answered "what good comes of it".

For completeness, would you mind answering, "what bad comes of it?"

------
dependenttypes
I think that this is an instance of ethical hacking. They hurry up to remove
any and all instances of PII before some hostile actor scrapes them while at
the same time punishing the people who leave their servers open without caring
for their costumers.

To whoever is doing that: you are doing god's work, please keep it up.

------
29athrowaway
Search engines like shodan.io make it trivial to discover unsecured databases
exposed to the Internet.

~~~
hobofan
What I don't get about Shodan: Why aren't all unsecured databases found
instantly (at the moment Shodan went online), but recurring attacks/dumps like
this one that rely on it? Do they update their crawl data in waves?

~~~
jcrawfordor
One real limitation is getting data out of Shodan. Having done a few different
projects that involve large-scale use of Shodan results (e.g. several hundred
thousand records), this kind of thing usually ends up costing $300 for either
export credits or a service plan. Sure, $300 isn't really _that_ much to cause
millions in damage, but I think it's a big factor in why we don't often see
Shodan used for huge-scale malfeasance. You both have to put up the money and
in paying you probably give up some identification info, and I don't know if
Shodan has complied with law enforcement in the past but I can sure see them
getting a warrant for "the person who just spend hundreds to export and/or
query every unsecured MongoDB."

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.

~~~
achillean
We're actually getting rid of export credits because it's caused confusion
over the years. We now just have query credits to download data/ do searches,
and scan credits for users that want to request on-demand scans. We announced
this change in the most recent Shodan Update newsletter. You can already use
our new website ([https://beta.shodan.io](https://beta.shodan.io)) to download
data using your query credits.

Export credits were the first way I tried to monetize Shodan and it became a
legacy system that lots of companies used so I was hesitant to get rid of it
until something better was in place.

I'll also add that the API was purposely not designed for downloading lots of
search results. The API is designed for security operations center (SOC) use
cases. Companies that need large-scale, bulk access to our data would need to
check out our enterprise platform
([https://enterprise.shodan.io](https://enterprise.shodan.io)).

~~~
jcrawfordor
This is what I've assumed, but it's in a pretty uncomfortable place right now
as e.g. the documentation often refers to export credits with a broken link.

The API is somewhat unsuitable for exporting large volumes because it seems
remarkably unstable as to ordering, it suggests that you can do paginated
requests but the second page tends to have 30% overlap with the first page.

I 100% understand the product motive to move large exports to an "Enterprise"
feature, but it's rather disappointing because as a small-scale independent
operation I don't expect to be able to afford it, and that would go for a lot
of productive people in security research. But then, that's capitalism.

~~~
achillean
I decided that a broken link is better than having people spend money on
something that will be deprecated. We're obviously working on cleaning up
those broken links but it's an easy thing to explain if anybody emails
support@shodan.io

The ordering is based on timestamp and it can happen that new results were
indexed in between your 1st request and 2nd request which creates an
overlapping result. A 30% overlap is unusual and sounds like it's for a query
with many results.

Finally, most researchers don't actually need to download data. They could
just use our free API and facet queries to get the information without
downloading the actual data. This entire website is powered by a free API key
that uses facets:

[https://exposure.shodan.io/#/](https://exposure.shodan.io/#/)

I think a lot of researchers go into the default mode of "I want to have the
data" but using facets is way easier, faster and doesn't cost any money at
all. And you can navigate the available facets using our new beta website
(another area we're trying to make things a bit clearer). For example:

[https://beta.shodan.io/search/facet?query=http&facet=http.co...](https://beta.shodan.io/search/facet?query=http&facet=http.component)

Note that we provide free upgrades to universities/ students/ professors as
well as routinely work together with researchers so we're not trying to push
them into the enterprise product. We also let universities monitor up to ~120k
IPs for free using Shodan Monitor
([https://monitor.shodan.io](https://monitor.shodan.io)). But the use cases
for researchers are few and we figure that if you need lots of data then you
can send us an email.

------
Havoc
Meh. Maybe it’ll get devs to pay attention to database security.

------
nautilus12
Why is mongodb seem to show up alot with this. Does their default set up hide
some unsecured users? Its been a while but I dont remember that being in
there.

~~~
akx
No, their default sets up no authentication at all IIRC. Combined with
Dockerized installations punching through some firewall setups (as discussed
elsewhere), you'll get meowed.

~~~
achillean
By default though, MongoDB will only listen on localhost and I believe it'll
show you a big warning on boot up if you don't have authentication configured.
They used to listen on 0.0.0.0 by default but that was fixed many years ago.

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...](https://blog.shodan.io/elastic-data-exposure-grows-to-3-2-pb/)

------
userbinator
I wonder if you can find a remote code execution vulnerability in client
libraries for one of these databases, and set up a few honeypot databases...
you might be able to catch who's doing it and retaliate. The legalities of
doing that are certainly questionable, but then again, so is this.

------
b123400
If this turns out to be an effective lesson on security, systems should
implement their own meow to protect their users.

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.

~~~
hinkley
If memory serves, Postgres will only listen on 127.0.0.1 unless the admin
password has been set.

All software should work like that.

~~~
steffan
MongoDB listens only on localhost by default since 3.6 (2017)

~~~
hinkley
You are allowed to judge people for taking far, far too long to do the right
thing.

It indicates a pattern of poor judgement, which speaks to trust. You know they
are going to let you down each time a new issue comes up.

Faulting people for being cautious around such bad actors (which I'm not
saying you're doing, but the response will) speaks to _your_ judgement, not
the vendor's.

------
based2
[https://arstechnica.com/information-
technology/2020/07/more-...](https://arstechnica.com/information-
technology/2020/07/more-than-1000-databases-have-been-nuked-by-mystery-meow-
attack/)

------
mulmen
Seem like this could be easily reconfigured to do the opposite. Leave the
databases but overwrite all the existing data then write dummy data until disk
is exhausted. Does that cross another ethical line?

~~~
andai
You mean, to make data recovery impossible?

~~~
mulmen
Or just to run up costs, which is the potentially new ethical line.

------
gregschlom
So why is the attack being called Meow?

~~~
phoe-krk
Seems like all that's left of a database after the attack is some generated
indices or other data structures with their names ending with "meow".

~~~
scurvy
Clearly fans of "Super Troopers" / BrokenLizard.

~~~
to11mtm
Meow why would you say that?

~~~
gravitas
Probably because a bunch of stoners are putting a password on their database
right meow.

~~~
jt94mf90d
Meows right!

------
ddrt
Not to be disrespectful it is there a more reputable source that doesn’t
jackhammer ads down the users throat every other paragraph?

~~~
northwest65
If you see ads on that page you are interneting wrong. I'd really encourage
you to install an adblocker.

------
dvfjsdhgfv
It took way too long. When you have a company that builds a great product with
no security whatsoever and makes their business model based on selling the
security module on it and changes their behavior only when threatened by a
competing open source product, you have to wonder when the catastrophe comes.

Note I don't blame anyone, it was just bound to happen.

------
faebi
Is it legal to access them if they are unsecured?

~~~
bdcravens
Legality is determined by permission, so no.

~~~
alain_gilbert
Do you have permission to access HackerNews (:rolleyes:) ?

You access it because it's publicly available...

------
joana035
Lets return the computers back to sysadmins ;-)

------
dt3ft
After having read a number of articles talking about data leaks on a gigantic
scale, I decided to check it out. Because shodan is not free to use/behind a
paywall, I wrote a simple windows console tool which scans all known Azure
subnets for unsecured elasticsearch instances and logs the results. I was
baffled by the amount of instances this tool found within the first few hours
:( To say that security in IT is getting out of control would be an
understatement...

~~~
achillean
Doing aggregate queries is free - only if you want to download actual data do
we start charging money. You could just do the following via the CLI using a
free account:

$ shodan count product:Elastic org:Azure

This entire website is powered by a free API key:
[https://exposure.shodan.io](https://exposure.shodan.io)

------
dredmorbius
Any statements by Shay Banon?

Crickets AFAICT: [https://twitter.com/kimchy](https://twitter.com/kimchy)

Also: [https://twitter.com/elastic](https://twitter.com/elastic)

------
bcrosby95
People are talking about more responsible disclosure. Is it feasible to even
track down the owners of 4,000 different unsecured databases, much less go
through the whole process with them to ensure the database is properly
secured?

~~~
akx
Some of these attacks leave a calling card sort of thing, e.g. a database with
a document that says "hey, lock your stuff up".

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

------
Zenst
Given some VPN's and other secure services that got used in Hong Kong turned
out to have open logs as just resold services.

So one wonders how many people will be positively effected by this.

------
3gg
This is bad when it comes to personal data, like the VPN provider that claimed
not to be logging. Companies should spend every effort to secure people's
data, and can face large fines in the event of a leak. In erasing the data,
Meow is also erasing the evidence of their crimes. Instead, Meow should ransom
the data and set a fine proportional to the company's size, revenue, the
sensitivity of the personal data, whether that personal data should have been
collected in the first place, whether that data should be public-facing, etc.
Then Meow can be made a public service, perhaps paid with taxpayer money, and
bring about justice.

------
andrewstuart
Can someone how/explain why databases are left open?

~~~
achillean
Short answer: cloud images with poor defaults. I've written about this a few
times before and the problem hasn't really changed since the article was
posted:

[https://blog.shodan.io/its-the-data-stupid/](https://blog.shodan.io/its-the-
data-stupid/)

------
baxtr
I wonder about the motive. Why would anybody do this without blackmailing or
even telling people. Maybe it was a frustrated sysadmin... :/

~~~
foolfoolz
why would anyone want to have their work be talked about all across the
internet and become part of internet history??

~~~
baxtr
Fair enough!!

------
Chris2048
on the UFO VPN leak:

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

------
heretoo
Hippocratic Oath: "First, do no harm".

~~~
tremon
And the Hippocratic oath applies to online vigilantes how, exactly? Right now,
I think these actions are causing more good than twenty years of lacklustre
legislation have done, worldwide.

~~~
heretoo
That was aimed at everyone on this thread that feels comfortable with deleting
databases that they don't own.

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.

------
kabacha
Might be very immature of me but attacks like this still make me crack up as
if I was still a teen in YouGotPwned web times.

------
snorrah
It’s 2020, where security should be at the forefront of almost any tech
endeavour. It’s not something to think about afterwards, not any more.

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 ?

------
vulcan01
I've got some Heroku projects, which don't have a static ip. How do I protect
myself against this?

~~~
Linkd
Simply set a secure password on any DB instances exposed to the internet.

~~~
vulcan01
Ah, I see. So no need to find a static IP to use :) Thank you.

~~~
quasarj
I mean, if the database is not directly available on the internet, that would
be a great help as well.

~~~
Linkd
Agreed, password is the bare minimum.

------
pabs3
I wonder what proportion of these are just PII that should never have been
collected in the first place?

------
Bootwizard
What exactly does "unsecured" mean in this sense? The article never explains
the attack

~~~
steffan
Started up exposed to the internet and listening on 0.0.0.0...

...and also not enabling a password

------
heretoo
If you really believe this action is warranted, as I've read on this thread, I
challenge you to tweet under your real name "I will delete your data if you
don't secure it", and add it to your resume/CV as one of your strengths.

------
ComodoHacker
There's some gray hat job well done here.

------
kalium-xyz
I wonder if its going after RATs, heh

------
woah
Seems like kind of a public service

------
dillonmckay
How do they determine ‘almost 4k’?

~~~
afrcnc
Shodan and BinaryEdge search results

------
sova
HTTP Delete makes a come back in spectacular fashion

------
sarasasa28
why are only meme databases affected?

------
agustif
Already waiting for meow(two)

------
contrarianmop
I prefer this over having data stolen.

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.

~~~
glenstein
>I prefer this over having data stolen.

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.

------
p3rry
Damn, last week we were wondering where did our data went and why there are so
many meow indexes! We were meowed !!!

~~~
GekkePrutser
The cat's out of the bag now!

------
pmarreck
Why must some people insist on being assholes?

~~~
spoopyskelly
> Why must some people insist on being assholes?

The ones leaving giant databases unsecured? At least they are being taught an
important lesson.

~~~
pantaloony
My blame scale for breaches, most to least:

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)

~~~
glenstein
Why is the person doing the deleting so low, relatively speaking, in your
ranking of people's responsibility for them doing the deleting?

Also, do you think that this person or persons would refrain from deleting the
data if they had the opportunity, but it qualified as a "good idea" to keep
online? I.e. they might review, say, medical records, spend some time thinking
to themselves whether it was 'necessary' to be online, and then decide to
delete or not delete depending on their judgment?

~~~
pessimizer
For me, it's because the odds of this person showing up quickly approach 1 as
time approaches infinity, and that person's effect would be nil if it weren't
for necessary causes 1) through 19).

Blaming the person that hacked you is like blaming the individual rock that
sinks your boat when you navigate too close to a rocky shore. The rock may
have done 100% of the damage to your boat, but if it hadn't been that rock, it
would have been another one.

~~~
pmarreck
I was hacked using what at the time was novel (but is now a known exploit):
someone claiming to be me transferred my SIM card to a new phone, over the
phone, which then enabled them to defeat my 2FA (which of course I've now
removed ALL cellphone recovery from).

Are you saying that it's my fault for either picking an insecure provider
(T-Mobile, who I absolutely bitched out and told them to put a note on my
account to not permit any SIM transfer without me physically being in a store
under a camera), or for not staying abreast of the very latest in social-
engineering exploits that assholes were using to try to steal bitcoins, and
manage my security accordingly?

------
Pick-A-Hill2019
Or 'Meow, I'm a Frog'

------
EGreg
How does this work?

Will it affect MySQL databases accessible from the Internet but secured with a
long random password?

~~~
Twirrim
Don't expose MySQL databases to the internet. Just don't. Stick an API layer
in at the very least with key based auth, and only the bare minimum
capabilities allowed for the user.

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.

~~~
gverrilla
I'm doing my first web project (self-taught), which is the prototype for an
offering me and a partner are developing to become a startup. I was about to
start deployment (for the first time in my life) this week, but now I'm
afraid. It's a flask app. We serve users forms (POST), then I use this input
to run calculations on the server through a python script which makes queries
to a MySQL db, then I return results to browser my listing a result-array
dynamically using a Jinja template. Is this unsecure? Any tip or accessible
reading material to help me understand this matter? We don't store credit card
info or other sensitive information for now, because we didn't reach any
clients yet, but final version should have at least login functionality. Any
light/knowledge/consideration will be much appreciated!

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.

~~~
dylan604
>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

Don't allow access to `mysql -h hostname` from WWW. Instead, keep your MySQL
server accessible only by machines you control in the same security
group/network/etc. To get access to the database from the public, create an
API that allows predefined queries only to users you've authorized. This API
would also be hosted within the same security group/network/etc. The public
never gets direct access to the database, yet gets the predefined access they
need.

