[HN Gopher] New 'Meow' attack has deleted almost 4k unsecured da...
___________________________________________________________________
New 'Meow' attack has deleted almost 4k unsecured databases
Author : based2
Score : 531 points
Date : 2020-07-26 14:58 UTC (8 hours ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| bcrosby95 wrote:
| 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?
| hinkley wrote:
| When that SQL Server worm was going around I had three or four
| different machines spamming my firewall trying to search for
| more victims, but I was only able to track one of the IP
| addresses back to contact information.
|
| That person was very grateful for the heads up, but the other
| three were SOL.
| akx wrote:
| 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...
| 29athrowaway wrote:
| Search engines like shodan.io make it trivial to discover
| unsecured databases exposed to the Internet.
| quaintdev wrote:
| https://www.censys.io
| hobofan wrote:
| 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?
| achillean wrote:
| A story like this pops up every year and preventing
| ransomware/ mass-deletion of publicly exposed databases has
| proven to be very challenging to stop from happening. I mean,
| I wrote about this issue 5 years ago:
|
| 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.
| onion2k wrote:
| People make new unsecured servers.
| jcrawfordor wrote:
| 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 wrote:
| 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) 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).
| jcrawfordor wrote:
| 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 wrote:
| 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/#/
|
| 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...
|
| 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). 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.
| user5994461 wrote:
| Works great. You can already find questions on Stack Overflow
| from people getting their database deleted
|
| 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
| rodgerd wrote:
| I wonder how much customer info they were leaking before then.
| Izkata wrote:
| The question was posted early Friday morning. If this drove
| their services, I suspect a lot of us would've known about it
| a lot sooner than now...
| pramodhs wrote:
| 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 wrote:
| 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 wrote:
| > 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).
| ljm wrote:
| First thing I always do on any new VPS is to sort out SSH
| (disable root login, disable password login), set up
| fail2ban, install and configure ufw... and if I need to set
| up something like redis or similar, make sure it only listens
| to internal connections and also that it is decently auth'd.
| For deployment and other things I make users that can only
| write to certain directories; no sudo. It's nothing new or
| special but it gets lost in distributed systems.
|
| It's a lot more work when doing it in the cloud and spinning
| up these things from docker containers in K8S...but you're
| entirely to blame if you don't know what you're deploying and
| don't understand any of the potential threats.
| mdoms wrote:
| Atlassian is not on Google Cloud, they are an AWS shop. I
| suspect this is an unrelated personal project.
| pietroglyph wrote:
| Sounds like a good public service. I'd much rather have my data
| deleted until it's secured than have it stolen by someone else.
| randyrand wrote:
| depends on the data. it could be public records
| qrbLPHiKpiux wrote:
| Good.
| mhh__ wrote:
| Oops no welfare for you!
|
| I understand that some people won't learn without
| encouragement but it's not a good thing for all.
| ljm wrote:
| This attack uses public write access, which is how they
| can delete stuff. I think we can agree that this is not
| good, and I also think we can agree that a database
| shouldn't be exposed as-is without an application layer
| or API on top
|
| Ultimately, companies like MongoDB and Elasticsearch are
| culpable for selling database technology that is insecure
| by default, presumably because that's the easiest way to
| boost their metrics for the VC overlords.
| smt88 wrote:
| Databases can be public and secure. If a database can be
| deleted, it is not secure.
| cryptoz wrote:
| Vandalism is not a good public service.
|
| > I'd much rather have my data deleted until it's secured
| than have it stolen by someone else
|
| There are multiple logical fallacies in this sentence. First
| is the use of the world 'until' which is ambiguous here; it
| suggests that your data can be 'undeleted' after the DB has
| been secured or you would rather not have any data stored
| anywhere that is not secured. Either option to me seems like
| an incorrect read of your comment but I'm not sure. And "than
| have it stolen by someone else" seems to imply that you know
| that this data was never copied and cannot be stolen still. I
| think that seems incorrect, unless there is something I
| missed that assures everyone that the data could not have
| been stolen during these hacks.
|
| Lastly, your personally preferred outcome for your personal
| data is not a measure for all of society, but you grant it
| that "public service" label as if your preference matters
| above everyone else's. You don't know what other people think
| about their data. You don't know what the data even is. What
| if some of it was just a hobby project for someone, with no
| financial implications of unsecured data or of data loss, but
| with emotional attachment to their data? Do they not matter
| to you?
|
| A blind deletion of unknown data belonging to unknown people
| is not a public service.
| p1necone wrote:
| I assume the comment was partially in jest. But this would
| actually work well if it was consistent and fast. If
| databases get wiped before you have time to put anything
| important in them then noone gets hurt.
| [deleted]
| dmurray wrote:
| Yeah, it's bad for the industry right now, but this is
| just a transition period! Once we get through the pain of
| losing a few databases, the new steady state where
| nobody's data is stored in world-writable databases will
| be better for everyone, and that will be worth the cost.
|
| Consider if this happened five years ago, it would have
| had a smaller cost than happening today. And it was
| probably going to happen at some point, so better that it
| happened five years ago than today. By the same argument,
| better that it happened now than at any point in the
| future.
|
| I'm not sure how serious I am about this argument
| but...at least a little bit? I guess the alternative
| argument is that any day now software vendors would have
| all moved to secure-by-default platforms where deploying
| a world-writable Redis in production would have been so
| difficult that it rarely happened.
| rodgerd wrote:
| If you can't look after people's sensitive data you don't
| deserve to have it.
| philshem wrote:
| The top-voted answer links to this HN page. I'm stuck in an
| infinite loop.
| m12k wrote:
| Nah, you're just in an unbounded recursion - don't worry, I
| can already now tell you that it ends with stack overflow.
| smabie wrote:
| Nah stack overflow learned their lesson and switched over
| to free monads.
| IncRnd wrote:
| Ha! Clever!
| oconnor663 wrote:
| I dunno, does Chrome implement tail call optimization? :)
| aledalgrande wrote:
| You should configure a timeout.
| inetknght wrote:
| Good tree^H^H^H^Hgraph traversal algorithms have a history
| stack specifically to detect and deal with loops.
| throwaway8941 wrote:
| >tree^H^H^H^Hgraph
|
| If we pretend we're using readline here, ^W (yank
| previous word) and ^U (yank to the start of the line)
| should save you some key presses.
|
| Some recommended bedtime reading:
|
| https://catonmat.net/ftp/readline-emacs-editing-mode-
| cheat-s...
|
| https://en.wikipedia.org/wiki/GNU_Readline#Emacs_keyboard
| _sh...
| hinkley wrote:
| These are not emacs commands. They aren't even unix shell
| commands. They are TTY commands, some of them dating back
| to the dot matrix teletype terminals.
|
| My favorite is ^U, which 90% of the time lets you start
| over on a password prompt when you are sure you just fat
| fingered but not sure how badly.
| djeiasbsbo wrote:
| Thank you, that one is really useful! The one I had
| always remembered was ^H for whenever no other way to
| delete characters works. I need it in some SQL REPLs
| which aren't configurable.
| red0point wrote:
| 1) If it's a tree, it ain't got no loops 2) The stack
| isn't to deal with loops, the ,,visited" flag at each
| edge is there for that. The stack (for DFS, BFS would be
| a queue) is there to keep track of which nodes have been
| visited such that you can construct a path from the
| starting node to the one you're looking for.
|
| Obviously there are variants to this, depending on what
| you're actually trying to achieve with it. My point is
| that a stack would be a very inefficient way to deal with
| loops.
| inetknght wrote:
| 1) you're right, I edited my message to reflect that I
| meant a graph traversal algorithm.
|
| 2) a visited flag on an edge? That won't support
| simultaneous traversals. Keeping a stack is a lot more
| efficient than permitting only one traversal at a time.
| red0point wrote:
| I'm not sure why you're bringing concurrency to the
| table.
|
| My point still is that looking something up in a stack
| (did I visit this node?) costs O(n) time, so the BFS will
| degrade from O(m+n) to O(m*n+n).
|
| To come back to the concurrency, if you can index your
| edges in some way, you can also store the visited flag in
| a separate datastracture to support concurrent access
| (one ,,flag store" for each access).
| hinkley wrote:
| Modifying the graph turns it into shared (mutable) state.
| Your code is still re-entrant, but it's no longer
| concurrent.
| hinkley wrote:
| You can cheese infinite loop detection by setting a max
| number of edge traversals (that way you don't just loop
| longer when someone speeds up the happy path).
|
| For real code, you wouldn't generate a web page with 5
| million entries in it, so you can be pretty sure that the
| data is bad even if it's not cyclical (but it probably is)
| nautilus12 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| gregschlom wrote:
| So why is the attack being called Meow?
| Nextgrid wrote:
| I believe they rewrite the records in the unsecured DBs with
| "meow".
| detaro wrote:
| Because it deletes data and only leaves records saying "meow".
| phoe-krk wrote:
| 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 wrote:
| Clearly fans of "Super Troopers" / BrokenLizard.
| to11mtm wrote:
| Meow why would you say that?
| gravitas wrote:
| Probably because a bunch of stoners are putting a
| password on their database right meow.
| jt94mf90d wrote:
| Meows right!
| phyzome wrote:
| Yeah, it was kind of amazing how the article never explained
| what exactly "meowing" entailed, and just left readers to
| figure it out from context.
| flywheel wrote:
| I really hate that this will be added to internet vernacular.
| It's become such a mish-mash of typos and puerile crap. 'pwned'
| has always been cringe-worthy to me. Not looking forward to
| seeing 'meowed' repeated ad-nauseam.
| bdcravens wrote:
| Cats like to knock things off of tables.
| faebi wrote:
| Is it legal to access them if they are unsecured?
| kl4m wrote:
| Not any more than walking in the street and trying car doors.
| Avamander wrote:
| Bad comparison. This is akin to someone random walking into a
| restaurant and looking under the fryer and finding a dead rat
| and removing it with the fryer.
| bdcravens wrote:
| Legality is determined by permission, so no.
| [deleted]
| alain_gilbert wrote:
| Do you have permission to access HackerNews (:rolleyes:) ?
|
| You access it because it's publicly available...
| based2 wrote:
| https://arstechnica.com/information-technology/2020/07/more-...
| dt3ft wrote:
| 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 wrote:
| 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
| vulcan01 wrote:
| I've got some Heroku projects, which don't have a static ip. How
| do I protect myself against this?
| Linkd wrote:
| Simply set a secure password on any DB instances exposed to the
| internet.
| vulcan01 wrote:
| Ah, I see. So no need to find a static IP to use :) Thank
| you.
| quasarj wrote:
| I mean, if the database is not directly available on the
| internet, that would be a great help as well.
| Linkd wrote:
| Agreed, password is the bare minimum.
| TwoBit wrote:
| Are the databases being meowed lacking any passwords?
| steffan wrote:
| At least in the case of MongoDB, yes. Listening on all
| interfaces and not having a password set.
| steffan wrote:
| If you're using MongoDB Atlas, you can allow connections only
| from a specific subnet. Also, you should of course set a
| password or use x.509 certs.
|
| 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.
| EE84M3i wrote:
| What does a static IP have to do with this?
| b123400 wrote:
| 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 wrote:
| 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 wrote:
| MongoDB listens only on localhost by default since 3.6 (2017)
| hinkley wrote:
| 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.
| dillonmckay wrote:
| How do they determine 'almost 4k'?
| afrcnc wrote:
| Shodan and BinaryEdge search results
| [deleted]
| TA00001 wrote:
| For those that want to go deep link diving. 'Meow, I'm a Cat'.
| contrarianmop wrote:
| 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.
| mekkkkkk wrote:
| > I prefer this over having data stolen.
|
| How do you know it wasn't?
| glenstein wrote:
| >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.
| andrewstuart wrote:
| Can someone how/explain why databases are left open?
| achillean wrote:
| 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/
| quasarj wrote:
| Ignorance.
| heretoo wrote:
| 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.
| GekkePrutser wrote:
| 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.
| DonHopkins wrote:
| The Cat Game is no laughing matter.
|
| https://www.youtube.com/watch?v=1rlSjdnAKY4
| isatty wrote:
| > 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 wrote:
| 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.
| cdrini wrote:
| 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...).
| 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 wrote:
| > 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 wrote:
| 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.
| webo wrote:
| Who do you think should regulate the "public"? ISPs, police,
| government?
| cdrini wrote:
| I don't know :( But this feels like some sort of terrorist
| tactic, and I don't think this should be the way things on
| the internet are regulated either.
| cdrini wrote:
| Actually, that's one of things that makes this frustrating.
| Because there is no real regulation, a group/individual
| decided to "become" the law. The became lawmaker, judge,
| and executioner. They decided what was illegal, collected
| the guilty, and punished them for it. That's what makes
| this feel like a "Wild West" situation. The made themselves
| regulators of the internet.
| grahamedgecombe wrote:
| In the UK it's probably already illegal under the Computer
| Misuse Act, as it'd fall under "unauthorised modification of
| computer material".
|
| I assume other countries have similar laws.
|
| That said, enforcing it is a different matter.
| cdrini wrote:
| Yeah, I think enforcement is probably a big part of what
| keeps the internet a "Wild West" for these cases; and
| improvements to enforcementability could fundamentally alter
| what the internet is :/
| more-coffee wrote:
| Yeah, I don't think the internet can be fundamentally
| altered to the extent that it could be regulated. Unless it
| somehow becomes a major priority for the world leaders - in
| which case I'll bet we can say goodbye to any privacy we
| still had.
|
| It's been said before plenty of times, but I think the
| solution has to be sought in increasing awareness of the
| dangers of the internet. Compare it to the electrical grid.
| 99% of people would not mess with it without
| consulting/hiring an expert. Not just because it's illegal,
| but because of the obvious danger. But for the
| informational grid, "nobody" (exaggerating) cares because
| they cannot oversee the consequences.
|
| Problem then is, how do you educate people about this... I
| don't know.
| cdrini wrote:
| Actually, a good physical example is restaurant health
| inspections. They're responsible for testing the safety of an
| organisation, and making sure that data is publicly visible,
| and in extreme cases, shutting the organisation down for
| negligence.
| hinkley wrote:
| Electrical and building safety code.
|
| 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.
| [deleted]
| hinkley wrote:
| For people who pride themselves on going 'faster' than previous
| eras of innovation, we seem to ignore the fact that we have now
| been the 'Wild West' for longer than the actual Wild West...
|
| Sort yerselves out.
| MauranKilom wrote:
| 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 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 wrote:
| 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-...
|
| 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...
| Pick-A-Hill2019 wrote:
| Or 'Meow, I'm a Frog'
| agustif wrote:
| Already waiting for meow(two)
| bronlund wrote:
| This reminds me of the old days. Today a virus usually tries to
| go undetected and does a number of things, but back in the days -
| if you got a virus, you were fucked :)
| Chris2048 wrote:
| 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.
| monksy wrote:
| 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.
| ShaneMcGowan wrote:
| But the profits...
| acdha wrote:
| 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.
| sarasasa28 wrote:
| why are only meme databases affected?
| rectang wrote:
| 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.
| dilandau wrote:
| What about developers just being competent before deploying a
| database on the public internet?
|
| At least google "securing X" before just pumping data in.
| dimitar wrote:
| Apparently these guys don't have a firewall setup and haven't
| heard about private networks and VPNs.
|
| _reads TFA again_ Wait, one of the victims is a VPN
| provider???
| TwoBit wrote:
| I've read that there are now VPN providers that just use
| someone else's VPN engine. So they don't have to know wtf
| they are doing.
| dehrmann wrote:
| For a product that's 50% snakeoil and marketing, that
| approach seems reasonable? It's easier than actually doing
| the leg work.
| IAmEveryone wrote:
| That's just victim blaming. The same logic applies to every
| crime: "lock your doors if you don't want your TV to be
| stolen!".
|
| It also works at any level of security: "Lock your doors and
| hire guards if you don't want clever thieves breaking a
| window..."
|
| But if you require everyone to take adequate measures to
| physically secure their houses, you don't even need laws and
| morality!
|
| And while this may provide the sort of negative reinforcement
| you are hoping for, actual damages in each case are going to be
| all over the place. That makes this one of the worst possible
| punishments. Imagine the penalty for speeding is a random
| outcome somewhere between a stern reminder and the death
| penality. There would be nothing fair and little useful about
| that, even though it does follow the same basic principle of do
| bad -> be harmed.
| tdeck wrote:
| Why not just rename all the tables or something? That's enough
| to get the developer's attention without being so destructive.
| nkrisc wrote:
| Because if it's not destructive they have no reason to pay
| attention. Change names back and it's business as usual.
| nisa wrote:
| It's also easy to get bitten by Docker. You can secure your
| server with iptables/ufw only to discover that docker happily
| punches through your firewall and you need to filter on the
| DOCKER-USER chain - and even that was broken:
| https://unrouted.io/2017/08/15/docker-firewall/
| https://github.com/docker/for-linux/issues/690
| nisa wrote:
| link for the missing DOCKER-USER chain:
| https://github.com/docker/for-linux/issues/810 - so if you
| are unlucky you are one apt upgrade away from data theft...
| jwr wrote:
| Yes, this is terrible, and when I discovered this, I was
| appalled how it seemed no one was taking this seriously.
|
| When you use ufw with a default DENY policy, you tend to
| assume that whatever isn't explicitly listed gets DENIED.
| This is not the case with Docker, and I think it's just a
| matter of time until someone loses big because of this issue.
| dawnerd wrote:
| 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.
| usmannk wrote:
| Isn't exposing ports in your docker-compose
| services:redis:ports, how you'd do that? (Docker hobbyist
| here)
| jcrawfordor wrote:
| My guess would be that they went with "ports" instead of
| "expose" which makes it public. But even with careful
| composition of your docker-compose you might want to be
| careful, Docker can interact with iptables in surprising
| ways and long iptables rulesets are almost comically
| difficult to validate sometimes. The result is that if
| you're using both Docker (and even more if you use
| Compose, Kubernetes, some other orchestrator) and doing
| anything else with iptables (including using it as a host
| firewall) you need to take a lot of caution to make sure
| you don't mess anything up. These tools usually confine
| their changes to custom chains to make this stuff easier
| to sort out but at the same time it can make it more
| difficult to understand what's happening, particularly
| with the use of tagging and etc.
|
| In general I would recommend putting some kind of
| protection between machines running Docker (and
| especially orchestrators) and the internet. This could be
| cloud provider mechanisms (security groups, ACLs, etc), a
| firewall appliance, NAT gateway configuration, etc.
| depending on the situation. It's not _necessary,_ but it
| makes the situation easier to audit /validate, and more
| layers of protection seldom hurt. If nothing else it
| means that much of the time you'll need to make a mistake
| in two places instead of one, in order to have an
| unintended exposure.
| gerdesj wrote:
| "and long iptables rulesets are almost comically
| difficult to validate sometimes."
|
| Use nmap to evaluate your policy from the outside, don't
| try to validate it in your head by inspection.
| acdha wrote:
| Use Shodan.io's monitor feature and you'll get alerting,
| too.
| gavinray wrote:
| Friendly FYI, "EXPOSE" is a no-op that is only meant as
| visual documentation to end-users. "The
| EXPOSE instruction does not actually publish the port. It
| functions as a type of documentation between the person
| who builds the image and the person who runs the
| container, about which ports are intended to be
| published."
|
| Second paragraph:
|
| https://docs.docker.com/engine/reference/builder/#expose
| jcrawfordor wrote:
| I'm referring to docker-compose, where 'port' and
| 'expose' are container configuration options that behave
| differently from the Dockerfile keyword.
|
| Although the similar words with different meanings no
| doubt contribute to confusion.
| gavinray wrote:
| Ah, my mistake. That comes off pretty asinine then,
| apologies.
| lol768 wrote:
| I've said it on here before, but the way in which Elasticsearch
| used to lock away critical security functionality (like TLS
| support and RBAC) behind a paid subscription whilst making just
| enough functionality available for free such that users could
| shoot their foot off is disgusting. This only ever changed
| after Open Distro for Elasticsearch came onto the scene and
| forced Elastic's hand.
|
| I entirely agree the vendors are (partially) to blame here.
| bmcahren wrote:
| This is why we are refactoring our database to be able to
| migrate to Amazon documentdb from MongoDB. Encryption at
| rest.... Pay up!
| tyre wrote:
| Curious, why do you use Mongo? Does it give you something
| that a JSONB column in Postgres wouldn't?
| StriverGuy wrote:
| If you have ever used Mongo Atlas, you would understand
| why people use mongo. The administration ease that the
| platform provides is unmatched by any other DBaaS I am
| aware of.
| scandox wrote:
| Maybe they have 10 years of code sitting on it? It's what
| a colleague calls sound historical reasons.
| [deleted]
| BossingAround wrote:
| Surprisingly, I feel Mongo has been kind of surging back
| into developers' minds. I thought Mongo was utterly dead,
| and I also don't know why would one use Mongo instead of
| JSONB. The last I heard (3-4 years ago?), there were some
| fundamental problems with Mongo.
|
| That said, I've incidentally heard a lot about Mongo in
| the last half a year. Might be my bubble. Might be
| MongoDB actually maturing and getting really good. I hope
| it's the latter.
| lallysingh wrote:
| I mostly hear complaints about email spam from their
| salespeople.
| cpursley wrote:
| Yes, hipster cred.
|
| For everyone else, JUP ("Just Use Postgres")
|
| Snark aside, Postgres should hold you over for quite some
| time.
|
| With Postgres you probably don't need Redis, Elastic
| Search, Mongo or Kafka.
| hamandcheese wrote:
| I use jsonb heavily. While it is amazing, I definitely
| wouldn't rely on it as a general purpose replacement for
| NoSQL/schemaless data storage.
|
| An example of an issue I am dealing with currently: while
| you can create a gin index to speed up containment
| queries, Postgres doesn't keep any statistics about jsonb
| columns. This means the query planner will sometimes do
| stupid things, like using the index even for very non-
| selective overlap conditions, which is a lot slower than
| just doing a sequential scan.
|
| Less of an issue for me but worth considering: the size
| of the gin index in my use case seems to be about 5x
| bigger than the size of the unindexed data. I was
| surprised by the size increase. I only use the
| containment operator so I could make a smaller/faster
| index using the jsonb_path_ops operator class. This is on
| my todo list :)
|
| Like all non-btree indexes in Postgres, the index is
| unordered. That means sorting by values in the jsonb
| column will always be slow. This doesn't matter for
| selective queries, but exacerbates my already slow non-
| selective queries that return large result sets.
|
| That said, if your queries are selective, jsonb + gin
| indexes are surprisingly performant (in the 0.5-10ms
| range for small result sets). My use case is a mix of
| structured relational data with jsonb for user-defined
| values (which of course they want to use for
| querying/sorting and I was dumb enough to say "sure, why
| not?")
|
| In terms of the magnitude of data, there's roughly 10
| million rows. Each team using this service has the query
| scoped to about 500k-1 million records, and then
| additional filters (on the jsonb column) will scope that
| down to anywhere between 60k-0 results.
| BossingAround wrote:
| Well, it's just another attempt at monetizing the product.
| Nowadays, companies and developers expect everything to be
| OSS (and I love it) yet it's incredibly expensive to develop
| SW (and very few people do OSS just because of passion--I
| tried and failed miserably).
|
| Locking RBAC and TLS behind a paid subscription is a sure way
| to force companies with security teams to pay for it (or not
| to use it).
|
| This particular lesson comes relatively cheap--dropping your
| data is not the worst an attacker could do with it.
| Hopefully, more people will research what I'd call "security
| 101"...
| pavel_lishin wrote:
| > _Well, it 's just another attempt at monetizing the
| product._
|
| Don't make excuses for their shitty business practices.
| gameswithgo wrote:
| Don't tell people what to do.
| 908087 wrote:
| If this results in unsecured private data vanishing, and people
| who have no business handling that data taking a hit, more power
| to them.
| jb775 wrote:
| 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.
| userbinator wrote:
| 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.
| 3gg wrote:
| 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.
| p3rry wrote:
| Damn, last week we were wondering where did our data went and why
| there are so many meow indexes! We were meowed !!!
| GekkePrutser wrote:
| The cat's out of the bag now!
| epr wrote:
| The cat's out of the bag meow!
| kalium-xyz wrote:
| I wonder if its going after RATs, heh
| AznHisoka wrote:
| 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.
| stjo wrote:
| Metasploit kinda fits the description
| edoceo wrote:
| Run OpenVAS against your infrastructure. It's free cost, nearly
| free in time.
|
| Edit: I also do this as a service, have for years, and hammer
| my own system monthly.
| ZephyrBlu wrote:
| Ironically, when I go their website I get a warning because
| their certificate has expired.
|
| https://openvas.org/
| achillean wrote:
| 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).
| You just provide an IP/ network/ domain and we'll notify you if
| anything changes or becomes vulnerable. It's basically Google
| Alerts but for network ports:
|
| https://monitor.shodan.io
|
| Disclaimer: I'm the founder of Shodan.
| petee wrote:
| 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.
| glckr wrote:
| No other bad actors can get it, but we don't know if it's
| already been found, and now that it's gone we have no idea what
| data is out in the wild. And as you note, we can't trust the
| companies to accurately report it themselves.
| DyslexicAtheist wrote:
| maybe the authors of meow should "improve" it with a feature
| that reports every instance to HIBP before deleting it. that
| is if their intention with this malware was a benevolent one
| :) but I guess feature iteration in malware that is "supposed
| to be good" would be tricky
| mkagenius wrote:
| > reports every instance to HIBP
|
| no, that doesn't make sense if its only meow who found it.
| And since there is no way to know that, it does not make
| sense to mail a copy to hibp
| petee wrote:
| I think you make an important point though - deleted or not,
| there is no real way to know what's been exposed, and no
| guarantee that they'll ever admit it; so torch all the data
| expeditiously, and we'll just have to comb through
| 'successful' leaks just as always.
|
| Another side is that with their database blanked, that will
| force more companies to explain their downtime or complete
| loss of data, rather than quietly secure it again and pretend
| nothing happened
| Alex3917 wrote:
| Ideally they'd report it so that password managers could warn
| everyone, but with just the database URI there isn't
| necessarily any obvious way to know what domain or business
| its associated with.
| wtracy wrote:
| If the attacker can write to the DB, then they can add
| entries to every table with the string "Hey your database
| is unsecured!"
| GekkePrutser wrote:
| Doesn't really matter, as long as the credential is
| exposed, users can be warned. No matter where it came from.
| HappyDreamer wrote:
| Maybe this actor A downloaded the data, then deleted the
| database, preventing others from accessing and selling the
| same data? Only A can sell this data now?
| na85 wrote:
| So, no difference other than the company now has to explain
| that their database was insecure. Got it.
| zentiggr wrote:
| Oh, they'll have to say something when they suddenly stop
| doing business until a backup can get pulled, and the new db
| instances actually secured before putting them up again.
|
| Even a bland 'we lost parts of our data and we will have to
| start recovery processes. please stand by' is a signal.
| gwright wrote:
| Would you feel the same way if someone burned your house down
| if you left the door unlocked? Would you support the idea of
| people walking through a neighborhood and checking every door
| in a similar way? Does your opinion change if it happened in a
| business district?
|
| I think it is fine to argue that doors should be locked but
| that doesn't mean that a crime hasn't been committed when
| someone takes advantage of a situation.
| cm2187 wrote:
| I don't think the parent suggests it exonerates the hackers.
| Just that the clients are better off.
| gwright wrote:
| Better off? The idea that victims deserve to be victimized
| because they didn't take enough care is trotted out every
| time a security issue comes up on HN.
| [deleted]
| ThrowawayR2 wrote:
| These aren't victims; they were harmed through their own
| gross negligence or the gross negligence of the developer
| they employed.
| gwright wrote:
| They aren't victims? If you forget to lock your car door
| and it is stolen or something inside it is stolen are you
| also not a victim by your logic?
| wolco wrote:
| Thr victims are the unaware customers who's data has been
| stolen because the company wasn't providing security.
|
| If a business left the store open with the customers
| credit cards details on display. Anyone passing by can go
| in and copy that info. Someone sees this and burns the
| exposed records. Perhaps they helped the victim.
|
| Remember no one burned the store down or the table
| holding the records. They burned only the exposed
| records.
| gwright wrote:
| You don't know who was the storage vendor and who's data
| was being deleted and you have no idea what that data
| represents or what the consequences are of having to
| restore it.
|
| You are making several unfounded assumptions.
| wolco wrote:
| No one knows more information than the article presents.
|
| When you state that victims exist or that the data being
| deleted is important you are also making unfounded
| assumptions.
|
| You can't have it both ways.
| gwright wrote:
| I think it is entirely reasonable to start with the
| presumption that people have a right to their data and to
| their property, that it is valuable to them.
| wolco wrote:
| If a site/service has a right to allow a person to delete
| data. The machine can be setup however they like. These
| are not hacked databases. The system said welcome what do
| you want to do? You can read everything or delete
| everything or add anything.
|
| So they did.
| cryptoz wrote:
| > These are not hacked databases.
|
| Yes they are. The method of the hack was 'simple' to you,
| but that doesn't mean it's just magically not a hack any
| more. These are hacked databases.
|
| > The system said welcome what do you want to do? You can
| read everything or delete everything or add anything.
|
| I don't understand this. Are you suggesting that the
| attackers were greeted by the database with an English-
| language legal directive of what legal permissions they
| had in the database? What do you mean by this statement?
| Surely the databases said no such thing.
|
| If you're implying that a private door with no lock is
| _not_ private but actually shared property that can be
| destroyed or added to in any way, then I think you 're
| wrong. None of this comment makes sense to me. An
| unsecured database holding private data, or an unlocked
| door to a private business or building, is _not_ an open
| legal invitation for vandalism.
| wolco wrote:
| If you attempt to connect to a database the database will
| greet you. It can be configured to ask for a login. It
| can be configured to have no login. If it doesn't have a
| login and gives you a welcome prompt it's not called
| hacking. In order to hack something it needed to be
| secured to start with.
|
| Databases do greet users in mostly english. Need help?
| Type help. On the list of things the system allows
| deleting data appeared to be one.
|
| If you knock on a door and the door opens and says
| welcome what do you want to do (delete data, read data)
| and you pick delete it doesn't mean it's illegal
| vandalism.
| cryptoz wrote:
| > It can be configured to have no login. If it doesn't
| have a login and gives you a welcome prompt it's not
| called hacking. In order to hack something it needed to
| be secured to start with.
|
| I very strongly disagree with this. Can you cite
| somewhere that unauthorized database access is not
| hacking if there is no password? To me and I think the
| law that is definitely illegal and hacking.
|
| > If you knock on a door and the door opens and says
| welcome what do you want to do (delete data, read data)
| and you pick delete it doesn't mean it's illegal
| vandalism.
|
| Yes it does! If you don't have authorized access then
| that database isn't yours and entering it is illegal.
| rytis wrote:
| Except that I didn't leave the doors open. Someone I trusted
| with the keys, left them in their safe. Unlocked. So I rather
| have their whole place burned down and MY keys melted at the
| same time.
| gwright wrote:
| You are suggesting that it was just "keys" but that isn't
| the case here. You don't know what type of data is being
| destroyed.
|
| A better example might be a storage unit service that left
| the front gate unlocked. If someone torches the place to
| illustrate that they need better security would you be
| comfortable with that? Isn't there a better approach that
| we should encourage or is OK to encourage people to destroy
| things that aren't protected to teach people "lessons"?
| rytis wrote:
| Maybe. However, if this was my diary or photoalbum, bank
| statements, medical reports or anything of that sort I'd
| rather have them destroyed than knowing that they may
| have been copied... The lesson is not for the people,
| it's for the companies that take shortcuts to save money.
| It for the MBA's that think things don't have to be
| properly engineered.
| gwright wrote:
| So you are rationalizing a crime because it teaches
| companies a lesson? That is a crazy rejection of the rule
| of law. Would you be comfortable in applying that logic
| to all crimes?
| smichel17 wrote:
| I'm not gp, but let's take a step back for a sec.
|
| (I've mostly lived in the northeastern US)
|
| I live in a small (~20k population) rural technically-
| city (but... it's a town) where crime is not much of an
| issue; my car sits unlocked in my driveway and I seldom
| lock my house -- when I do, it's almost always when I'm
| _at home_ (alone) -- it 's about a _feeling_ of security,
| not any real risk of a break-in. I 've lived this way in
| this town for many years and have never experienced a
| robbery. I think it's pretty low risk, not irresponsible.
|
| I've also lived in a larger city. There, I absolutely
| locked my doors. And I've traveled to tourist-y locations
| known for pickpockets, and kept an even closer watch on
| my belongings.
|
| The internet is two orders of magnitude larger than the
| world's largest city and policing it is exceptionally
| difficult, since it spans national borders. There will be
| crime.
|
| I wish this weren't the case. I much prefer living in a
| safe place where I don't have to worry about locking my
| doors when I go out. But when crime is common, it's
| negligent not to protect against it.
| gwright wrote:
| I agree with all that and I also don't want to let the
| perpetrator off the hook. In your example, doesn't matter
| if the crime happens in a place where it is uncommon or
| not, it is still a crime and we shouldn't excuse the
| perpetrator by suggesting that the victim needed to be
| taught a lesson.
| sinsterizme wrote:
| I think the major difference is that losing my house along
| with all my belongings is much worse than losing just some of
| my belongings. Also data being exposed publicly can be used
| nefariously by multiple parties, so is likely worse in most
| scenarios compared to just outright deletion of the data
| gwright wrote:
| Ok, but losing "just some of your belongings" is bad also,
| right? When thinking about the culpability of the person
| deleting the data or storing the data, we have to start
| from the assumption that the owner of the data values it.
|
| Whatever analysis you want to put on the situation I don't
| think it is reasonable to start with the idea that some of
| the data might not be that valuable.
| zentiggr wrote:
| Either the data is something public (name, address, etc)
| in which case, whatever.
|
| Or it's data that was gathered (in line of business, for
| example) and its destruction is anywhere from more secure
| to an inconvenience.
|
| Or it's data that was aggregated beyond legitimate use
| (hey, FAANG) and by all means, tear it the hell up and
| throw it away.
| gwright wrote:
| Why do you feel it is important to characterize the
| nature of the data? The unauthorized deletion is wrong
| regardless of the nature of the data.
| lallysingh wrote:
| The first crime committed was leaving people's data out in
| the open.
|
| If someone had a list of names/birthdays/SSNs posted on their
| door, I'm not too unhappy if someone blacks out every line
| with the word 'meow.'
| gwright wrote:
| Not sure why you are focusing on the PII scenario. The
| original report seems to say it is just "unsecured
| databases" and not databases that have PII information
| posted.
|
| You are also making an subtle assumption that the service
| is being administered by a 3rd party. Could be that the
| service is being administered by the owner of the data.
|
| In any case it is still wrong to delete the data.
| zbuf wrote:
| I don't have a feeling one way or the other, but I see where
| you're coming from and I think there's an interesting aspect
| that many of the folks here seem to be missing.
|
| Were this sort of attack to become part of the "noise" of the
| internet (much as the continual bombarding of my SSH ports)
| then peoples databases would get deleted _before_ they contain
| any meaningful amount of data.
|
| So in practice this sort of gross vandalism is limited to the
| appearance of such an attack, but not ongoing.
|
| I had this the other day building OS images, which accidentally
| left the system a passwordless login. Within less than a few
| hours it was (presumably) spewing mail or doing awful things --
| long before anything went anywhere near production data or any
| kind of trust.
| koonsolo wrote:
| Who says it's consumer data? It can be a personal project, a
| blog, etc.
|
| Just because it's not secure doesn't mean you should delete the
| data, because where does such reasoning end?
|
| Reminds me of the super meat boy web version with database
| creds in client. Dev knew, but just did a quick implementation.
| Hacker wanted to prove his point and ruined it for everybody.
| Making a secure version was not worth the effort, so now
| because of this prick nobody could enjoy it.
| neutronman wrote:
| +1
|
| Any entity this irresponsible shouldn't hold data.
| derefr wrote:
| I'm ambivalent about this action in most cases, but in some
| specific cases there can be a clear reason to have an exposed
| database: namely when the database is a _guest-accessible,
| read-only_ repository of _public data_ , i.e. the self-hosted
| equivalent of publishing a Google BigQuery dataset.
|
| As someone who runs such a "public-access data library" myself,
| I would be slightly annoyed if someone came along and burned it
| down, just because it has an unpatched vulnerability.
|
| ...but if it got deleted because I left default admin creds on
| it, though, that'd be my own fault.
| jmvoodoo wrote:
| Databases that are read only would be unaffected by this
| attack.
| derefr wrote:
| Read-only in practice, not inherently read-only in the way
| that e.g. CD-ROM is. Such systems still need to have their
| otherwise-static dataset updated "online" by an ETL
| pipeline agent-user. Which often means, in the DBMSes with
| less fine-grained security models, that such users need to
| have full DML (and even DDL) capabilities, rather than only
| insert capability.
| dtech wrote:
| This attack was only possible on databases with unsecured
| or weakly secured read-write access.
| bhargav wrote:
| This also affected people who use software for things other
| than businesses. People with IoT apps for their home,
| researchers, etc.
|
| Our field is vast and there is a large variance in people just
| using the basics of CS and those who keep up with standards and
| best practices, etc.
|
| Your statement is basically akin to someone saying that it's
| fine for people to get robbed if they went out with their
| wallet; or worse.. killed.
| nend wrote:
| >Your statement is basically akin to someone saying that it's
| fine for people to get robbed if they went out with their
| wallet; or worse.. killed.
|
| Uhh no? The analogy would be that there's some benefit that
| comes from someone's wallet being destroyed, instead of
| stolen.
| unstatusthequo wrote:
| I'd say it's closer to leaving your wallet on the street.
| If you don't care to protect it you should assume someone
| will fuck with it.
| GekkePrutser wrote:
| Just putting a password on a database is more than a
| 'standard', it's truly common sense. Really, even a beginner
| should think of this. Otherwise they shouldn't be messing
| with this stuff.
|
| And if they do get 'meowed', lesson well deserved.
| hobs wrote:
| Just because its offering some useful service doesn't
| indemnify the ownership from the bad methods they use to
| deliver the service.
|
| Exposing your database to the internet with default creds is
| not "standards and best practices" - its highly negligent,
| and if you are taking people's money for such a service, I
| have no pity for you.
| tomc1985 wrote:
| Would you send or let people venture out into the Wild West
| in its heyday unprepared and unequipped?
|
| Why aren't we applying this same logic to CS topics? It's a
| vast world out there and much of it's out to get you. Be
| prepared or die.
| hddherman wrote:
| That's not a good argument, inexperience does not excuse
| exposing user data.
| petee wrote:
| If you can't or don't know how to secure it, it shouldn't be
| online.
|
| My argument is more akin to a child learning not to leave
| their bike unattended on a city street corner overnight. I
| can come by pick up the bike, and tell you the dangers, but
| there's only one real way to learn.
|
| And clearly my opinion isn't even close to comparison with
| somebody being killed in a robbery.
| HomeDeLaPot wrote:
| Yeah. I don't care if some big business loses their
| Elasticsearch data and their site stops working until they
| get it secured and re-hydrated with data from their
| relational database. Good, they learned a lesson.
|
| But I would feel bad if someone's small business had to shut
| down or lose a bunch of money because they lost all their
| customer data. I'd feel bad if someone lost all the data
| they'd been using for a personal project. If they didn't have
| backups and proper security, shame on them, but ideally they
| would be contacted and given advice. Ideally, their data
| would only be deleted if the effect would be minimal.
|
| On the other hand, if this is something that happens
| consistently -- all unsecured databases get deleted
| immediately -- maybe the data would be stolen less and
| everyone would have to learn their lesson early...
| acdha wrote:
| I'd feel bad if someone's hobby project was deleted. Small
| businesses losing customer data is only slightly more
| sympathetic than people getting sick because they didn't
| think the health code applied to them.
|
| If you collect it, you need to be responsible for keeping
| it safe. Anything affected by this is already exposed and
| has to be assumed to have been breached.
| Wowfunhappy wrote:
| What if it was a small business's inventory data rather
| than customer data?
|
| Seems to me, there are a lot of things businesses could
| store in a database which don't _necessarily_ need to be
| private, or which at worst won 't harm anyone other than
| the database creator if exposed.
| acdha wrote:
| That's why I was specific about customer data: it's
| basically a question of who's harmed - if the cost is
| borne by the person cutting corners it's more of a self-
| correcting problem.
| atyppo wrote:
| It's not a matter of "cutting corners." Think of all of
| the small businesses that recently moved online due to
| store closures. These businesses simply do not have the
| budget required to create something comparable to, say,
| Best Buy's e-commerce. Sure, Shopify might come close,
| but how do you think Mom and Pop will find and create an
| e-commerce solution?
| acdha wrote:
| That's the very definition of cutting corners. If they
| aren't confident of their ability to operate safely they
| need to either hire a professional or go without - just
| as not wanting to pay a plumber doesn't exempt you from
| meeting the health code or saving on accountants will be
| a get out of jail free card when you get audited.
|
| If it sounds like I'm unsympathetic, yes, that's true.
| Playing around with building your own database is a good
| learning experience but that changes once you expose
| other people to your mistakes. I've also dealt with a few
| small businesses and the people trying to run a business
| like this are _always_ trying to save a buck - they're
| the same ones who stiff contractors, avoid paying
| overtime, do their own taxes creatively, etc. If you have
| a successful business, you'll drop a few bucks on
| Shopify, Wix, etc. to focus on the business rather than a
| distraction.
| aledalgrande wrote:
| I'm not sure wiping out data from these unsecured databases
| is the answer, but even for amateur installations which
| have data of no relevance, the database could be used for
| nefarious things or the machine itself it runs on could be
| taken over and used for things such as DDOS attacks.
|
| In that sense, receiving a strong notification that your
| compute is available to anyone and you should secure it is
| a good thing.
| paulie_a wrote:
| Personally I hope this becomes so common place that it
| doesnt even make the news.
|
| Like the old days with slammer or codered
|
| It took 13 seconds for a freshly installed windows box to
| be owned when it was put online. Let those days return.
| colonwqbang wrote:
| > Yeah, I don't care if a big chain restaurant is closed
| down for having too poor hygiene. But I would feel bad if
| someone's small restaurant had to shut down because the
| cook doesn't bother to wash his hands at work.
|
| If you are holding other people's data for them, you have a
| responsibility to do your best to keep the data safe. If
| you don't know how to do that and don't have time to learn,
| you can hire someone who is more knowledgeable.
| gwright wrote:
| And what about the responsibility to not destroy
| someone's property?
|
| Do you have the same opinion about shoplifters walking
| away with merchandise? Would your argument be that there
| should be armed guards and searches in every retail
| store? Isn't it reasonable that a thief be criticized and
| penalized for their actions even if the theft was "easy"
| to commit and is it OK to blame the victim for not being
| prepared?
| smichel17 wrote:
| Agree with nkrisc -- this is like, if I contracted with a
| storage company, and then my stuff was vandalized because
| the company's "secure storage location" was an unlocked
| box out on the sidewalk. Obviously the vandal is directly
| to blame, but it's _also_ absolutely negligence from the
| company.
|
| I'm sympathetic for the people who were only storing
| their own data, but not for companies that failed to
| safeguard their customers' data. If I borrow stuff from
| friends, I take _better_ care of it than if it were mine.
| I hold companies to the same standard.
| gwright wrote:
| I'm not trying to disregard the negligence concern but I
| am trying to ensure that the perpetrator is also called
| out. Several of the top rated comments on this article
| are praising the perpetrator.
| nkrisc wrote:
| But it's my personal and sensitive data that they are
| poor stewards of, not their property.
| gwright wrote:
| I agree but I don't think that changes my point that the
| person who destroys the data has more culpability than
| the storage service in the destruction of the data.
|
| There tends to be a pass given to people destroying data
| and I don't think that is right.
| colonwqbang wrote:
| I agree, but I think it's beside the point.
|
| As engineers we have to assume that there is always
| someone out there looking to break into our systems. We
| don't get to blame them for our failure to secure our
| systems.
|
| For us to be angry at the hackers is as fruitless as it
| would be for the unhygienic cook to be angry at the
| bacteria.
| gwright wrote:
| Why are you making the assumption that I'm making the
| point "as an engineer" as opposed to just a citizen who
| thinks it is reasonable to expect people not do destroy
| something that doesn't belong to them?
|
| Your analogy about bacteria doesn't make any sense, we
| don't expect the bacteria to be actively seeking out
| unhygienic cooks. If you want to use your analogy it
| would be like having someone shake the cook's hand in
| order to put a mild irritant on their hands so that when
| they prepare food without washing or gloving their hands
| the irritant is spread to the food, thus highlighting the
| fact that the chef wasn't following good hygiene. Would
| you expect that behavior to be excused? Would you be OK
| with that if you were the one throwing up?
| colonwqbang wrote:
| You're presumably an engineer, I'm an engineer, this is
| an engineering forum. That is why I may have "assumed you
| made the point as an engineer".
|
| It sounds as if you think I'm defending the attackers.
| I'm not. I'm pointing out that the presence of malicious
| actors is a fact of life on the Internet, like it or not.
|
| I'm not going to take my analogy further. I think it's
| reasonably clear what I meant.
| colonwqbang wrote:
| You will notice that in my post I'm not defending the
| people behind the meow attacks. I agree, they are very
| much in the wrong.
|
| But being careless with other people's data is also wrong
| and we should not feel bad for companies whose negligent
| practices backfire on them. That is what I was trying to
| highlight with my analogy.
|
| Like bacteria, there will always be bad actors trying to
| exploit poor security. If not these attackers, then
| someone else. That is why we have security measures.
|
| The people we should feel bad for are the individual
| customers affected.
|
| Ps also, there is a big difference between being careless
| with your own property (your analogy) and someone else's
| property/data/wellbeing (my analogy and the case at
| hand).
| donmcronald wrote:
| > But I would feel bad if someone's small business had to
| shut down or lose a bunch of money because they lost all
| their customer data.
|
| Don't. When businesses of any size cut corners and provide
| services they aren't qualified to provide, it gives them an
| advantage compared to businesses that try to do it
| properly. They make more money or charge less and can often
| out compete competent owners. They'll also be the first
| ones to brag about how brilliant they are at business (in
| my experience).
|
| Small businesses are no exception. Delete away IMO.
| 52-6F-62 wrote:
| Said small businesses might have no idea their data
| wasn't secure. That would be on whoever developed their
| technology, not necessarily the business. Not all small
| businesses with customer or sales data is a technology
| company.
| hombre_fatal wrote:
| Seems like a lost opportunity to have a more nuanced
| position here. And when you can't think of a single case
| that could make you feel bad for someone, it's usually a
| sign that you don't have one.
| bhawks wrote:
| This is more akin to a person knowing the basics of driving a
| car but not which side of the road to use or what to do at a
| traffic light. They are a danger to themselves and others,
| the others in this case being the users of whatever services
| the unsecured databases provide.
|
| My sympathy for people learning the basics of our field and
| missing a few points stops when others are harmed.
| pizza234 wrote:
| Although the parent's analogy is arguably flawed, there's a
| very good point in the fact that there are users who are
| not involved in the implementation of the service - "People
| with IoT apps for their home". They're not drivers, to
| follow the driving analogy.
|
| It's unrealistic to expect that the population at large
| starts to pay a significant attention, in particular
| because the services/gadgets are a black box. How does one
| know if a device is safe? A layman surely can't; even
| somebody who's "just a dev" likely can't.
|
| Given the large-scale nature, probably some form of
| regulation would be the most realistic mitigation.
| Following the analogy, such users are taxi clients, and for
| similar reasons, taxis are regulated.
|
| With that in mind, certainly the engineering side of the
| equation should be held accountable. But it seems that the
| market is not punishing it at all.
| DoofusOfDeath wrote:
| > Given the large-scale nature, probably some form of
| regulation would be the most realistic mitigation.
|
| Rather than regulation, how about trademark-protected
| certification? I.e., similar to what Underwriter
| Laboratories ("UL") does for consumer electrical products
| in the U.S.?
|
| Except rather than the government _requiring_
| certification by UL or similar, organizations could
| simply decide for themselves whether or not to use
| uncertified products. And perhaps insurance companies
| could price certification status into relevant policies.
| bhargav wrote:
| Yup. My point is some people might not even know that
| their database is accessible from the web lol. It's
| pretty easy to follow a tutorial or get something OOTB
| that's not secure, so we shouldn't be saying we're glad
| this happened. Even if it's big businesses, what if said
| businesses were storing important data such as health
| records?
|
| I think the learn by failing is a good mentality but was
| hoping we can be mindful of the fact that this harms more
| than just the "big bad man"
|
| Edit: Addendum for a more thoughtful discussion, it would
| be great if these databases and tools provided some
| default security OOTB requiring no configuration
| whatsoever. Example: rather than creating user and
| password with root, is rather have some CMS site generate
| a random one!
| fiddlerwoaroof wrote:
| IoT is unlikely to be affected, unless the device goes
| out of its way to expose its database via upnp
| whoisthemachine wrote:
| This is my thought - why would an IoT device expose a
| database publicly? And if so, shouldn't the companies
| producing those devices not be following such bad
| practices? Maybe the consumer who bought such a device
| should go to the manufacturer and complain about being
| sold an inherently insecure device.
| rapind wrote:
| Legislation is just so far behind. User data is useful,
| but there should be requirements before you can just
| accumulate it. Cars are useful too but require a licence
| and insurance to drive.
| goatinaboat wrote:
| _Somehow I feel good about this._
|
| Frankly anyone who is still using MongoDB is professionally
| negligent and this was if not deserved then certainly
| inevitable.
| richardrk2 wrote:
| I wholeheartedly agree. I cannot think of a scenario where a
| company exposes my data and I would not want it to be deleted
| ASAP. The only thing is that such companies might not be able
| anymore (if data was not backed up) to email me about a
| "breach".
| asdfasgasdgasdg wrote:
| 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.
| TallGuyShort wrote:
| Just because it's understandable for Mom & Pop to not care
| about the privacy of the people whose data they've collected
| doesn't make it a good idea. They should care. If the buck
| doesn't stop with business owners, with whom does it stop?
|
| IMO we specialize too much and miss important things that we
| mentally outsource to other people. I'm equally disturbed how
| often I meet people in tech who are unable to do basic home
| repairs or cook for themselves. Something, like say, a few
| weeks of quarantine, and people's anxiety goes through the
| roof because they've relied on other people for basic life
| skills.
| cm2187 wrote:
| I am thinking more about the clients of the mom and pop shop
| who are better off not having their personal details exposed.
| jaggirs wrote:
| The possibility of someone stealing your identity (or worse)
| far outweighs the damages from losing some coupons.
|
| Deleting exposed databases is genious, there need to be real
| repercussions for companies if they leak user data.
| MattGaiser wrote:
| > The possibility of someone stealing your identity (or
| worse) far outweighs the damages from losing some coupons.
|
| That is a very rich person statement.
| tsimionescu wrote:
| Not really, it's much easier for rich people to reclaim
| their identity than it is for poor people.
| zentiggr wrote:
| Fine, what about every poor person who gets their data
| stolen from an unsecured database, and gets their
| identity stolen?
|
| Yours is also a rich person statement.
|
| Unsecured databases are a huge loss for everyone.
|
| Anything that forces a shift in this naive behavior of
| vendors, implementors and executives is not just fine by
| me, I welcome it. If my life suffers because of data of
| mine that's lost from companies' databases, I now know
| who to cease doing business with.
| jb775 wrote:
| But what about the companies making millions in profit each
| year that are carelessly exposing sensitive data because they
| don't want to spend a little more on quality IT work?
|
| No one wants to see their local pizza shop lose their pizza-
| credit database, but if that's the price to pay for data
| security then so be it.
| birdyrooster wrote:
| A spin class? Really that is the best example you can come up
| with? That is not at all compelling.
| asdfasgasdgasdg wrote:
| What part of the example do you dispute? Spin studios have
| databases, like almost all small businesses these days.
| birdyrooster wrote:
| If I knew we were frying fish this small Id a brought a
| different pan
| asdfasgasdgasdg wrote:
| 4000 small fish is a lot of biomass.
| jb775 wrote:
| What happens when mom & pop are storing your name and credit
| card # in plain text and then your identity gets stolen and
| credit ruined? Should we still be "charitable" to them and
| their d-bag nephew?
| jrockway wrote:
| Your credit card number being stolen is a problem for your
| bank, not a problem for you. You can't steal someone's
| identity with a credit card number.
|
| The concern in this case is when there is some social
| problem with being in Mom & Pop Inc's customer database.
| There are probably some people that buy some things that
| they don't want other people to know about. When the
| database gets hacked and you are linked to being their
| customer, that is the unfortunate and potentially damaging
| information leak. A credit card just gets reissued and the
| bank reverses the transaction. No big deal.
| gowld wrote:
| It's a problem for the vendors, not the banks. They get
| hit with chargebacks for fraud that's no fault of their
| own, hurting the whole ecosystem of vendors and their
| customers.
|
| https://www.thestreet.com/personal-finance/credit-
| cards/cred...
| lotsofpulp wrote:
| The problem could be easily solved by
| Visa/MC/Discover/Amex implementing chip and pin, or at
| least 2FA SMS authorization. Bestbuy.com has it working
| somehow.
| TwoBit wrote:
| It's still a PITA when my credit card has to be swapped.
| owaty wrote:
| > Your credit card number being stolen is a problem for
| your bank, not a problem for you.
|
| Not necessarily, depending on where you're based.
| rightbyte wrote:
| Ye it is not like I trust my credit card to strangers and
| let them walk away with it for a while.
| abbadadda wrote:
| lol im sorry but this is probably not the best go-to example
| of real world consequences:
|
| > What if one of the databases has a record of credits you've
| purchased at your local spin studio?
|
| p.s. bobby tables did it first
| Drakim wrote:
| 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.
| octodog wrote:
| Your comparison isn't fair - blowing the whistle is
| supposed to be a last resort. Internal disclosure and
| attempting to fix the issue collaboratively is always the
| first step.
|
| This attack is indiscriminate and is without warning, so it
| eliminates the possibility for database owners to fix the
| problem in good faith.
| phkahler wrote:
| >> but couldn't the same be said for somebody being a
| whistleblower for a company that doesn't following building
| codes?
|
| No. The equivalent would be exploiting their buildings
| weakness to cause them to collapse - maybe with people in
| them.
|
| Pointing out a vulnerability is not the same as
| demonstrating it.
|
| That said, a demonstration will get their attention more.
| asdfasgasdgasdg wrote:
| 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 wrote:
| 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 wrote:
| 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.
| TeMPOraL wrote:
| The problem is with the e-mailing part. A mom&pop is
| unlikely to track you down if you lock out their DB, but
| they'll likely report you to police if you contact them
| about it.
| Wowfunhappy wrote:
| Is an email from an anonymous address easier to trace
| than remote database commands?
| edoceo wrote:
| Yes. You need good logging on the vulnerable DB to trace
| the command - and if your DB is vulnerable it's a good
| bet you forgot the logging too.
|
| Emails have a bunch of info in the headers, so there is
| more meta-data in the email it self.
|
| Neither is perfect for finding the culprit but one
| scenario has zero meta-data and the other has some.
| jfk13 wrote:
| 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.
| vincnetas wrote:
| "Fix auth". Add item to todo list and just forget because
| there are other more pressing tasks to do.
| achillean wrote:
| Unfortunately it's rarely that simple. If you look at the
| currently exposed MongoDB instances you'll see that most
| of them are in the cloud without any obvious attribution.
| You could email the cloud providers and see if they will
| reach out to the end-user but chances are they already
| know about it. Here's an article I wrote on that subject,
| although it was related to industrial control systems:
|
| https://blog.shodan.io/taking-things-offline-is-hard/
| asdfasgasdgasdg wrote:
| I certainly think the most legal approach is to do
| nothing except notify, or maybe nothing at all. But if
| you must modify the database, locking it reversibly is
| more defensible morally.
| 908087 wrote:
| A large portion of your notifications would go ignored,
| and some portion of your notifications would likely
| trigger the owners of those databases to go on the attack
| against you.
| cheerlessbog wrote:
| Or just set everyone's password to the same thing eg
| SecureMe
| [deleted]
| markovbot wrote:
| > Are there databases that could be lost without consequence
| except to their owner
|
| I would certainly hope the owner of the insecure database
| would face massive consequences. IMO there's not _nearly_
| enough of that. This sort of breach should be financially
| ruinous for _any_ company.
| mod wrote:
| What if the database only contains my blog posts? Or my own
| personal health information I'm tracking? Or all the
| Hearthstone cards? Or any other of the infinite data sets
| that are totally insignificant to anyone beyond the owner
| of the database?
|
| Not everything is about you, and also you totally
| misunderstood the post you quoted.
| petee wrote:
| Then you'll learn real quick to secure your database,
| make backups, or not post personal stuff online.
|
| And if you've configured your database that poorly, am I
| supposed to assume you've properly configured your server
| against becoming part of a DDoS attack? Or a bot net? The
| base level of negligence you're defending enables a
| multitude of attacks. Losing your DB would be an
| immediate sign you don't know what you're doing, and thus
| shouldn't be doing it.
| mcv wrote:
| I don't find your example very convincing. Any database
| storing personal data needs to be properly secured, and if
| that gym also has ID credit card or other more sensitive
| data, that data might better be destroyed than stolen.
|
| If it's a publicly accessible wiki with no sensitive data
| whatsoever, and that's meant to be publicly accessible, then
| there's a reasonable excuse for the poor security and it's
| not helping anyone to destroy it.
| nxpnsv wrote:
| Why should innocent users be punished? Why not just send a
| pic confirming you have full db access? This is just
| unnecessary vandalism.
| tsimionescu wrote:
| The point is that, if my credit card info is staying in a
| web-exposed, insecure DB, it is safer for me that it be
| destroyed than left alone.
|
| I have no idea of that is the intention of the attackers,
| or if they are maybe even stealing the info before
| deleting it. But assuming they were good Samaritans and
| just deleting it, that is the best outcome for me as a
| user, better than if it stayed up for another day.
| wolco wrote:
| Somehow that would be worse. Feels like a ransom call.
| katbyte wrote:
| Because often that doesn't actually elicit change.
| Deleting the data over and over does.
| asdfasgasdgasdg wrote:
| There is no indication in this article that all of the
| databases had personal data.
| Tade0 wrote:
| _Like, how does the local mom and pop correctly evaluate a
| person 's IT chops?_
|
| Usually by price and unfortunately both mom and pop like a
| bargain - I've seen this play out more times than I would
| like.
|
| Also how do you evaluate, say, a landscaper's chops? Or any
| other kind of contractor's for that matter? By doing research
| beforehand, checking what kind of reputation that person has
| etc.
|
| Low-effort or lack of research gives you bad services, for
| which you pay in losses like these.
| evilduck wrote:
| In construction and landscaping work those companies are
| usually licensed, bonded and insured. If they fuck up the
| work there's obvious financial recourse. Also, the measure
| of them fucking up is generally a lot clearer for physical
| labor and for mom and pop businesses, getting construction
| work inspected by a 3rd party is usually more
| straightforward and cheaper.
|
| In software, financial recourse generally means you have to
| jump straight to lawsuits. There's no licensing for who's
| qualified to build a website, developers don't have to
| escrow funds or carry malpractice insurance in case they
| make a mistake, a development business should have
| insurance in place but there's not always easy or
| affordable ways to assign fault in most IT situations if
| you want to pursue them. Software and IT forensics are
| prohibitively costly and usually mean a lot of money has to
| be on the line which rule out mom and pop businesses
| entirely. IT and software mistakes also usually take longer
| to rear their heads, and people in IT and software also
| aren't known for sticking around for decades. How do you
| sue an LLC that dissolved 5 years ago?
|
| It's apples and oranges in my opinion.
| Tade0 wrote:
| I don't how it is in the US, but in my country an audit
| that would reveal such an obvious lack of security costs
| no more than the equivalent of a single minimum salary -
| usually much less. On top of that several companies that
| offer such services are widely known because their media
| presence is mostly articles about vulnerabilities in
| routers, phones, operating systems etc.
|
| I hail from a post-communist country so I assumed the
| culture in the US is more developed in this regard.
| bcrosby95 wrote:
| If someone does a shitty job in home improvement stuff
| it's usually not visible for years down the line. And
| good luck with your recourse by then. I've never heard of
| a homeowner getting recourse unless it's insanely
| obviously bad right away. The vast majority end up just
| living with the defects or hiring someone else to do the
| job again.
| wott wrote:
| 10-years warranty is a thing and is mandatory in some
| places/countries.
| RcouF1uZ4gsC wrote:
| > What if one of the databases has a record of credits you've
| purchased at your local spin studio?
|
| Usually when you buy something, you get an email receipt. So
| you print out your email receipt and go to the mom and pop
| store.
|
| Given they are a local mom and pop store, you likely have a
| long term relationship with them and they may even remember
| you buying credits. So it will be a hassle, but likely ok.
|
| It is the huge corporate stores that don't have long term
| relationships that would be hurt by this thing the most.
| JaggerJo wrote:
| agreed.
| klyrs wrote:
| > Somehow I feel good about this.
|
| For me, it's not exactly "good." But I am more upset with the
| database owners than I am with the kitties. Don't leave the
| barn door open, or this (or worse) will happen to you, and
| happen again. If they were instead exfiltrating and selling the
| data, the equation would change. I'm not saying the cats are
| doing good, but I do say that the "responsible adults" did the
| greatest harm by not cat-proofing their databases that contain
| PII.
| menzoic wrote:
| Could be both
| baxtr wrote:
| I wonder about the motive. Why would anybody do this without
| blackmailing or even telling people. Maybe it was a frustrated
| sysadmin... :/
| foolfoolz wrote:
| why would anyone want to have their work be talked about all
| across the internet and become part of internet history??
| baxtr wrote:
| Fair enough!!
| Bootwizard wrote:
| What exactly does "unsecured" mean in this sense? The article
| never explains the attack
| steffan wrote:
| Started up exposed to the internet and listening on 0.0.0.0...
|
| ...and also not enabling a password
| nickjj wrote:
| 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
| imglorp wrote:
| There were several redis remote execution holes, not just the
| config file one, so pretty much anybody with an open redis was
| going to get trouble.
|
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=redis+remot...
| 1023bytes wrote:
| Currently there is crypto mining malware infecting exposed
| Redis servers (kdevtmpfsi)
| GekkePrutser wrote:
| 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.
| EGreg wrote:
| How does this work?
|
| Will it affect MySQL databases accessible from the Internet but
| secured with a long random password?
| Twirrim wrote:
| 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.
| PanMan wrote:
| Most SAAS db providers provide their database over the
| internet, but secured with a login/pass. Eg all DB's on
| Heroku elements marketplace work like this.
| GordonS wrote:
| You can also usually lock it down by IP address.
| GekkePrutser wrote:
| Yes, or they provide an internal subnet only accessible
| to servers from the same tenant. Usually it's double
| useful because usually this traffic is not charged.
| SahAssar wrote:
| That makes any number of assumptions about the API layer,
| what "key based auth" is used and what data the database has.
|
| 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.
| watermelon0 wrote:
| It's not strictly necessary, as long as there are no known
| vulnerabilities, and you use sufficiently hard password.
|
| However, it's highly recommended you never expose such
| services to the public, or at least limit allowed IP ranges.
| [deleted]
| Twirrim wrote:
| > as long as there are no known vulnerabilities
|
| That's really not something you should be gambling on.
| Assume the worst, and architect based on it.
|
| Limit what can be exposed where / how (e.g. as you say, "at
| least limit allowed IP ranges", but to me that's absolute
| bare minimum)
| gverrilla wrote:
| 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.
| kazagistar wrote:
| It sounds like you are probably fine. Your python flask
| script is the API layer. Just make sure it can only run sql
| that you want it to run (ideally, read only until you get
| it authenticated), and that it escapes user input, and that
| no one except admins have access to the actual db
| underneath, and you are totally fine.
|
| Also, for that matter, its a good idea to run backups too,
| just in case something goes wrong and you need to restore.
|
| This is literally people allowing users to run arbitrary
| commands on their fully exposed db, and then being
| surprised when someone runs a delete.
| dylan604 wrote:
| >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.
| jeroenhd wrote:
| Your API, in this case, is basically your Flask application
| so you're pretty much done.
|
| If you want to run a database securely, you configure a
| decent password (should be asked during installation),
| create new users for each application/database (easy with
| tools like MySQL workbench) and make all applications
| running on the server (Flask, in this instance) connect to
| localhost/127.0.0.1. Don't expose services like databases
| to the outside world if you cannot in any way help it.
|
| Then enable a firewall on your server (Ubuntu server comes
| with UFW by default) and lastly use a port scanning tool
| like nmap/zenmap to check if you have left any services
| other than HTTP(S) exposed.
|
| I don't know much myself about Flask deployments
| specifically, but you'll probably use something like nginx
| or Apache to handle the actual web requests. There's an
| article here [0] on how to do that. After you've done that,
| you can secure your connections for free through Let's
| Encrypt clients like certbot [1] which handle most of the
| configuration for you.
|
| TL;DR:
|
| 1. Configure your application to connect to localhost with
| a secure password
|
| 2. Enable a firewall, run "nmap <your domain>" to check if
| it works (should only expose HTTP(S) and probably SSH if
| you did it right).
|
| 3. Install nginx or Apache to handle requests for you and
| follow the guide at [1]
|
| [0] https://www.digitalocean.com/community/tutorials/how-
| to-depl...
|
| [1] https://certbot.eff.org/instructions
| WrtCdEvrydy wrote:
| It's fine to expose MySQL to the internet, but it better
| before set up securely.. and you better be using the
| database-level user security.
| traceroute66 wrote:
| "Don't expose MySQL databases to the internet."
|
| 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. ;)
| alecco wrote:
| I don't mean to sound harsh, but if you are asking yourself
| this question you need security auditing ASAP.
| EGreg wrote:
| Not at all. There could be some new vulnerabilities in MySQL
| that make even password-protected databases vulnerable.
|
| As for us, we give access via an SSH tunnel, which requires
| public keys from certain IPs.
| jacekm wrote:
| No. The bot targets only unsecured Elastic databases, i.e. ones
| where no credentials are necessary to execute queries.
| pmarreck wrote:
| Why must some people insist on being assholes?
| spoopyskelly wrote:
| > Why must some people insist on being assholes?
|
| The ones leaving giant databases unsecured? At least they are
| being taught an important lesson.
| pantaloony wrote:
| 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 wrote:
| 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?
| pantaloony wrote:
| Mostly because it's a very effective way to ensure things
| get fixed, while gaining the "attacker" nothing. It's
| harmful, but so is finding 4000 insecure databases,
| sending 4000 notification emails, and having 3950 of them
| ignored (and that approach is probably _more_ risky, so
| far as inviting legal trouble and expenses). It also
| neatly removes anyone else 's ability to take the data.
| pessimizer wrote:
| 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.
| Havoc wrote:
| Meh. Maybe it'll get devs to pay attention to database security.
| macleodan wrote:
| Cats like knocking stuff off tables.
| BossingAround wrote:
| Brilliant!
| t0mmyb0y wrote:
| Awesome.
| davidbrennerjr wrote:
| 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 wrote:
| 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 wrote:
| So, you've answered "what good comes of it".
|
| For completeness, would you mind answering, "what bad comes
| of it?"
| dilandau wrote:
| Victims are not the DB admins. Victims are the people whose
| private data, or data they expect to be private, is exposed due
| to developer incompetence.
| heretoo wrote:
| Hippocratic Oath: "First, do no harm".
| tremon wrote:
| 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.
| [deleted]
| joana035 wrote:
| Lets return the computers back to sysadmins ;-)
___________________________________________________________________
(page generated 2020-07-26 23:00 UTC)