Slashdot Mirror
Over 800 Million Emails Leaked Online By Email Verification Service (securitydiscovery.com)
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.
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.
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*
Butt whan
admin.
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."
(R)ule in Hell or (S)erve in Heaven [R]?
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?
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
What is "email validation" primarily used for; legitimate purposes, or spamming?
Off
- 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
Will $CURRENT_YEAR be the year of the Linux Desktop?
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.
Is there an accreditation organisation these fellows belong to?
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.
The "Civilized World" jumped the shark ca. 1973.
C'mon someone had to say it!
When asking for an email address is not justified, always use throwaway valid fake email addresses like admin or postmaster @<website> and similar and if feeling merciful spam@<website>
When rarely fails then pick a variation with gmail.com.
Done.
So you think this company was stupid for not securing thei mongo db ?
Take a look at Constant Contact's "security" model.
First and foremost they "outsource" their API ti Tibco which is already a giveaway of their technical proficiency. They use Tibco Mashery to deploy their API, but instead of implementing a short lived Access Token with Renewal Token Logic, they issue a 10 YEAR Access Token (ATK) through their development portal and there is no electronic way of revoking it !!!
AFAICT their API has no ACL for the API access itself so if the token is leaked, anyone with the app_key could do any operation on that account, this includes downloading the client lists, creating campaigns and sending mass emails through the hacked account:
http://developer.constantcontact.com/docs/developer-guides/overview-of-api-endpoints.html
The only way to revoke the ATK is by sending a request to Constant Contact support, and they've acknowledged this publicly since 2014:
https://community.constantcontact.com/t5/Authentication-and-Access-ie-401/Regenerate-Access-Token/td-p/225628
Not to mention that Tibco Mashery DOES provide an API to revoking a token but Constant Contact decided not to implement it:
https://support.mashery.com/docs/read/mashery_api/20/oauth_supporting_methods/methods/revokeAccessToken
Bear in mind that projects involving constant contact are usually done by Web Designers (a.k.a. Web "Programmers") who in turn outsource the development in whole or in part to resources in India, China, Russia or wherever, so these tokens travel through unencrypted email and are also stored in file servers and code repositories. Just imagine how many of these tokens are out there in the wild since Constant Contact is one of the more popular options for spamming, or should I say " email campaigning".
All this is shamefully public, and they just done't seem to care or maybe they don't even understand it! Somewhere in Constant Contact's documentation it says that they moved to OAuth 2 to replace the "old" HTTP Basic Authentication scheme for better security.
Anyway I've always found that all these "modern" authentication schemes (OAuth, SAML and even JWT) still pale in comparison with "legacy" yet truly secure authentication/authorization protocolos such as the 1993 rfc2617 (the original version that uses MD5) is probably still today WAY more secure than most OAuth 2 implementations in the wild today.
I mean, seriously?? How does an api_key / ATK pair differ from user/password?? and how does THAT differ from HTTP BASIC AUTH ??
But that's not the worse part. PC Magazine recently evaluated Constant Contact and even THEY did not pick up on this horrible security flaw:
https://www.pcmag.com/article2/0,2817,2474133,00.asp
Honestly we are evermore appalled at the stuff we are finding nowadays. People somehow think that "token" is somehow more secure that "password", and we are generally finding that companies are evermore completely ignorant on very obvious security flaws like these.
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.
"Mongo only pawn in game of life."
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
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.
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.
Of course I'd reject paying for it. data wants to be free. it told me itself.
its the rent-duh-k0d3rz putting the shit up there, thats whom to blame. most k0d3rz are incompetent and can't think beyond the next step.