Firefox monitor can tell you if your information was leaked in data breaches. I don't think they have this data set though. https://monitor.firefox.com/
can't I search for my phone number?
Personal and social information of 1.2B people discovered in data leak
191–200 of 440 posts
Re: Personal and social information of 1.2B people discovered in data leak
#192Re: Personal and social information of 1.2B people discovered in data leak
#193Earlier quoted context omitted.
I've been using ES off and on since before 1.0 came out. It has always baffled me that ES doesn't require a username and password by default. ES is a database that has to exist on a network to be usable. Heck, it expects that you have multiple nodes, and will complain if you don't. So one of the first things you do is expose it to the network so you can use it. Yes, it takes some serious incompetence to not realize y…
They offer security as a paid feature.
Actually it comes for free now with the standard ES distribution. https://www.elastic.co/blog/security-for-elasticsearch-is-no...
Re: Personal and social information of 1.2B people discovered in data leak
#194I found a vulnerability in linkedIn a few years back that allowed anyone to access a private profile (because client side validation was enough for them I guess..?) They didn't take my report seriously (still not completely patched) and I feel like that told me all I needed to know about their security practices.
While not good, what's the connection to this story?
The article says some LinkedIn data was scraped, but I don't see anywhere that it specifically says a LinkedIn security flaw was used in the scraping. Although it is vague about what data was scraped and how, so it doesn't preclude that either.
In other words, are you saying a LinkedIn vulnerability was exploited here, or suggesting that it probably was, or are you just mentioning LinkedIn because it's tangentially related?
Re: Personal and social information of 1.2B people discovered in data leak
#195Earlier quoted context omitted.
I've been using ES off and on since before 1.0 came out. It has always baffled me that ES doesn't require a username and password by default. ES is a database that has to exist on a network to be usable. Heck, it expects that you have multiple nodes, and will complain if you don't. So one of the first things you do is expose it to the network so you can use it. Yes, it takes some serious incompetence to not realize y…
It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products). If you are running mysql or postgres on a public ip address it would be equally stupid and irresponsible regardless of the u…
That does give me some food for thought. Not sure I agree a username and password is pointless though.
Re: Personal and social information of 1.2B people discovered in data leak
#196Yet another Elasticsearch server wide open. This is going to make the flurry of open mongodb servers look trivial.
I wouldn't be surprised if the starting point for this vulnerability wasn't ES, but Docker. Docker by default modifies iptables and if you hack together a system that uses both software running directly on the host and in containers, it's going to expose the forwarded containers to the Internet - which you might not be expecting, since a bind to localhost would be enough to expose a service. It's always a good idea t…
Great point. Depressing how such large profile projects can have such insane defaults.
Re: Personal and social information of 1.2B people discovered in data leak
#197Earlier quoted context omitted.
https://gdpr.eu/companies-outside-of-europe/ it looks like it would? I'm no expert though.
> The whole point of the GDPR is to protect data belonging to EU citizens and residents. The law, therefore, applies to organizations that handle such data whether they are EU-based organizations or not, known as "extra-territorial effect." They can say this all they want, but if you have no presence in the EU, and your jurisdiction does not have any agreement to apply GDPR regulations to you, then this is at most a…
One obvious answer in that case would be to establish who is buying the data from them and treat any PDL data as potentially tainted. If you find a downstream customer who does have a presence, then investigate accordingly. You might not be able to fine PDL directly, but you could certainly make the offending data risky or unprofitable...
Re: Personal and social information of 1.2B people discovered in data leak
#198Out of curiosity how do you guys think they managed to scrape LinkedIn on such a large scale? I've been wanting to do some social graph experimentation on it (small scale - say 1000 people near me) but concluded I probably couldn't scrape enough via raw scraping without freaking out their anti-scraping. (And API is a non-starter since that basically says everything is verboten).
So far, the answers have contained non-technical answers like "Distributed Scraping." Well, yes, obviously. A more useful answer is: I did this once, many years ago. Back then it was a matter of hooking up PhantomJS and making sure your user string was set correctly. Since PhantomJS was – I think – essentially the same as what headless chrome is today, the server can't determine that you're running a headless browser…
As long as you are able to source more than one provider, this can work well enough. If you're dependent on a single data source, e.g., because that source is the only possible source of said data, you'll get nuked from orbit by legal rather than technical means.
I had a business that was generating more money than my full-time job for a while. We helped and greatly simplified matters for several thousand independent proprietors while having a positive effect on the load of the data source, since we were able to batch/coalesce requests, make better use of caches, and take notification responsibilities on ourselves.
Once in a while someone would get worried and grumpy at the data source and there were a couple of cat-and-mouse games, but we easily outwitted their scraping detection each time. When they got tired of losing the technical game, they sent out the lawyers, which was far more effective. We were acquiring facts about dates and times from the place that issued/decided those dates and times, so there wasn't really any reliable alternative data source, and we had to shut down.
The glimmer of hope on the horizon is LinkedIn v. HiQ, which seems poised to potentially finally overturn 4 decades of anti-scraping case law, but not holding my breath too hard there.
Re: Personal and social information of 1.2B people discovered in data leak
#199I was at an Elasticsearch meetup yesterday where we had a good laugh about several similar scandals in Germany recently involving completely unprotected Elasticsearch running on a public IP address without a firewall (e.g. https://www.golem.de/news/elasticsearch-datenleak-bei-conrad... , in German). This beats any of that. Out of the box it does not even bind to a public internet address. Somebody configured this to…
ES, Mongo, Redis used to be some of the easiest targets for production data (security vuln wise). Deployed by SWE's usually, with products that were early versions, and didn't have access control by default.
Re: Personal and social information of 1.2B people discovered in data leak
#200Earlier quoted context omitted.
I've been using ES off and on since before 1.0 came out. It has always baffled me that ES doesn't require a username and password by default. ES is a database that has to exist on a network to be usable. Heck, it expects that you have multiple nodes, and will complain if you don't. So one of the first things you do is expose it to the network so you can use it. Yes, it takes some serious incompetence to not realize y…
It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products). If you are running mysql or postgres on a public ip address it would be equally stupid and irresponsible regardless of the u…
> It has to exist on a private network behind a firewall with ports open to application servers and other es nodes only. Running things on a public ip address is a choice that should not be taken lightly. Clustering over the public internet is not a thing with Elasticsearch (or similar products).
I've met at least one cloud provider in the past (small Dutch thing) that provides _only_ public IP addresses. They do have customers, though one less now. Clustering over the public Internet is a thing. It shouldn't, but I could say the same thing about this website and yet here we are.