Over 800 Million Emails Leaked Online By Email Verification Service

Security researchers Bob Diachenko and Vinny Troia discovered an unprotected MongoDB database containing 150GB of detailed, plaintext marketing data -- including hundreds of millions of unique email addresses. An anonymous Slashdot reader shares Diachenko's findings, which were made public today: On February 25th, 2019, I discovered a non-password protected 150GB-sized MongoDB instance. This is perhaps the biggest and most comprehensive email database I have ever reported. Upon verification I was shocked at the massive number of emails that were publicly accessible for anyone with an internet connection. Some of data was much more detailed than just the email address and included personally identifiable information (PII). This database contained four separate collections of data and combined was an astounding 808,539,939 records. As part of the verification process I cross-checked a random selection of records with Troy Hunt's HaveIBeenPwned database. Based on the results, I came to conclusion that this is not just another "Collection" of previously leaked sources but a completely unique set of data. Although, not all records contained the detailed profile information about the email owner, a large amount of records were very detailed. We are still talking about millions of records.

In addition to the email databases, this unprotected Mongo instance also uncovered details on the possible owner of the database -- a company named "Verifications.io" -- which offered the services of "Enterprise Email Validation." Unfortunately, it appears that once emails were uploaded for verification they were also stored in plain text. Once I reported my discovery to Verifications.io the site was taken offline and is currently down at the time of this publication.

MongoDB security is stupid

[Anonymous Coward]

the way you go about setting up users is unlike anything I've ever seen before. You also need to use --auth when starting the daemon just to enable authentication.

*sigh*

Re:MongoDB security is stupid

[jellomizer]

There is a lot of stupid things about MongoDB. On the top of the list is actually a lack of an Official Open Source Good quality GUI tool to manage it.
Sure it sounds silly and not a big deal, as anyone who knows MognoDB can run it from the command line... However the problem is most implementations of software is not from experts of the product, but from people using it for the first time.
Here is how it goes.
I have a project, I gather the specs, I find that a NoSQL database engine is a good fit. Now I try to do research on a NoSQL I see that MongoDB is the popular choice, figuring if the product grows, I can then find other resources who have experience in the engine later.
So then I start the project... I have no prior experience with MongoDB, Now, I am not stupid, I follow the documentation to get it going, and I get it to a point where I can attach my code to it. However I am Naive my lack of experience makes me blind on what is happening, with this new tool. There are features I don't know about, security defaults which may be different from what I am use to, so even as a in general experienced developer, I make a lot of mistakes.

Now tools like SQL Server Management Studio, pgadmin... gives me options to see what the product is doing, look at the setup and see what else I can be doing.

Re:MongoDB security is stupid

[olsmeister]

that sounds oddly specific.

Re:

[doconnor]

Anyone who knows enough to create one, doesn't need it any more.

Re:

[BringsApples]

Your "how it goes", didn't go so well.

Re:

[fluffernutter]

I've always been able to use relational databases with an ORM layer to accomplish my goals. Am I missing anything by not using this or is this just hipster 'its too hard to learn more' kind of stuff?

Now arrest the reporter

[The_Other_Kelly]

Cue Corporate PR Release:

"All of these problems have already been solved!

Anyone who accesses a computer system without permission is a criminal.
The poster did not have permission, so should now be arrested and prosecuted.

As for the business, one cannot expect hard working business owners to be
aware of every single little incident or problem.

If there was ever a problem, which cannot be proven with incriminating evidence of intrusion,
then it was merely a rogue employee failing to uphold the highest levels of data privacy,
protection and regulation, which the company expects from all employees and agents.

So nothing to see here, move on, keep quiet, keep smiling, ...
Enjoy the fish."

Know what you are doing.

[fluffernutter]

All these companies have to do is know what they are doing. That's it. Why is that too hard to ask?

On the other hand, why would any cloud provider not have several fail safes for a customer to go through in order to open a DB directly to the internet?

Re:

[Anonymous Coward]

All these companies have to do is know what they are doing. That's it. Why is that too hard to ask?

Well, why let a little thing like lack of technical competence stand in the way of a perfectly good business model?

So many 'tech' companies these days seem to have no actual skills in the tech they purport to be experts in, and it really is time to have legal liability for shit like this.

To me this is yet another example of a company who probably should never have been in the industry in the first place, becau

Re:

[Anonymous Coward]

Because they will never, ever, see a courtroom. They'll face no fines while deflecting any and all blame onto others.

Welcome to unchecked capitalism.

Re:

[fluffernutter]

Socialism weighs the punishment for the corporation by the true human cost with no regard given to the financial health of said business afterwards.

Email Validator?

[kackle]

What is "email validation" primarily used for; legitimate purposes, or spamming?

Re:Email Validator?

[Zocalo]

Almost universally, they're bottom feeders in the spam world. They purport to take email lists from customers and filter out the defunct ones, which they basically do by a combination of looking for accepted RCPT TOs when connecting to a mail server, or actually sending an email and seeing which addresses get bounced. This is something that any legit operation with a proper sign up process and using legimate mail service providers should be easily capable of handling automatically because they'd know every email on the list was valid from a confirmed opt-in and could remove any that repeatedly give an SMTP 5xx (hard fail) on delivery attempts (with some wiggle room for misconfigured servers/full mailboxes giving 5xx hard fails instead of 4xx transient fails). It's also a neat email address harvesting method for spammers; set up a verification service, wait for people (mostly other spammers) to send you their mailing lists for list washing, add them to your own lists, and then spam away and/or re-sell them on the dark web to other spammers.

As an aside, I have quite a number of these services hard-coded to 5xx regardless of the validity of the email they are testing in my mail server config. So far I've not noticed any legit mailing list I've actually signed up to stop working as a result, but I have noticed a fairly significant drop in the amount of spam I'm getting, which seems like a pretty good indication of who their primary customers are as well.

Re:

[kackle]

Interesting and informative; thank you.

A lot of errors

[grumpy-cowboy]

- Unencrypted sensitive information
- Opened database port on the internet (I suppose)
- Probably weak user/password (ex: mongo/mongo)
- They sent spams to verify email. Unsollicited emails are illegals in many countries (at least in Canada)
- MongoDB

Repercussions???

[Poison.Pill]

Is it just me, or should their be both Civil and Criminal penalties for companies who do crap like this?? Sure, it hurts them in the public eye, but then the public moves on to tornados in the south, drought in the west, or something the orange man did.

I"m starting to wonder if these are deliberate

[TigerPlish]

Yes, I know, cockup before conspiracy. Yet I can't help but wonder if these leaks are orchestrated by insiders in the company to accomplish some goal.

1. Scrape data
2. Put it up for easy discovery
3. ???
4. Profit.

Step 3 is what I can't figure out.

Re:

[Ol Olsoc]

Yes, I know, cockup before conspiracy. Yet I can't help but wonder if these leaks are orchestrated by insiders in the company to accomplish some goal.

1. Scrape data 2. Put it up for easy discovery 3. ??? 4. Profit.

Step 3 is what I can't figure out.

Aliens?

Re:

[TigerPlish]

Step 3 involves downloading the data from outside the company and selling it.

Too obvious. Can't have it be tied back to the inside agent. Has to be laundered somehow. Someone is making money on this, guaranteed. Can't figure out how.

MongoDB is web scale

[ben_kelley]

C'mon someone had to say it!

Re:

[Anonymous Coward]

But /dev/null has even better write benchmarks!

Email Validation

[Maximus23]

From the Article "They do this by literally sending the people an email. If it does not bounce, the email is validated." This is not always accurate. I work for an email security company, and our recommendation for incoming messages, if the email address isn't valid, mail sink the messages, and don't give any notification. Optionally, have a second rule that's applied to business partners to bounce messages to let them know they got the wrong address, and bounce at that point.

Also had to be said:

[Toad-san]

"Mongo only pawn in game of life."

Apply GPDR

[Eric.pl]

If any of these emails come from Europe, apply GPDR. Fine the company (€20 million or 4% of global annual turnover for the preceding financial year) and reduce our taxes accordingly

Who cares?

[DatbeDank]

It's just email addresses. My spam filter works so well, I doubt anyone of them will get through.

And if one does, I block it. No big deal .

Not a big deal.

Devs don't know what they're doing

[ilsaloving]

MongoDB is a great example of a product that is popular, not because it's good, but because it's easy for developers to get up and running when they don't have the skills to do anything else.

And this is bad, because it has enabled developers to do things that they don't even understand, let alone do it properly, and this article (and the many similar articles that have come before it) are the logical conclusion whenever you make a technology available that enables the unskilled.

And it doesn't stop there. They made MongoDB easy for the the developer, and *only* for the developer. Anyone down the line that may need access to the data is completely screwed unless they a) are also a developer, and b) have the time to write their own app just to interact with the database.

IMO MongoDB, and similar database systems, and the single worst step backwards that modern technology has ever accomplished. It has bypassed almost 50 years of hard won database knowledge, and developers are sucking it up cause it lets them ignore the management of their entire data layer.

Re:

[ledow]

Letting developers bypass normal network management procedure is a real dumb idea.

The core blame is not that of the product, but of the lack of respect given to its deployment. A developer shouldn't BE ABLE to just create an database instance and expose it to the entire Internet, of anything that you run on a huge service like that.

Testing should be internal and isolated. Production should go through the normal channels of approval. And a network management team should be making sure they aren't reliant