Millions of emails leaking from sites to advertising and analytics companies

Numerous Enterprise Organizations Leaking User Emails Through 3rd Party Javascript Request Headers Sent via Browsers to 3rd Party Advertising & Analytics Companies

Each of these orgs leaked user emails by unsafely appending the user email to a URL in plain text (or encoded in base64) and then having the user emails leak to 3rd party advertising and analytics companies.

When any 3rd party Javascript code loads on a website, metadata from the user and the website can be transmitted to the 3rd party domain / company that controls that code — this is technically through the “Request Headers” sent through a browser — and this data can include what page a user is visiting, what type of device and browser they are using, their location, and other forms of fingerprinting / cookies / URL querystring/ URL parameters that are used by advertising and analytics companies.

This type of email user data in a URL bar synced into Javascript pixels is most typically blocked by a regular person through “Ad blockers” or through browsers like Safari, Brave, and Firefox — those browsers use Javascript/cookie blocking as a default features to protect users (each browser handles it slightly differently). This breach and research included here would impact all Chrome users of these websites who went through these specific user flows and who didn’t proactively block all Javascript (a rarely used option) or use a Chrome “Ad blocker” extension that blocked this type of Javascript. Some people using the other “safe” browsers (Safari/Brave/Firefox) could have been protected from the leak due to their 3rd party Javascript requests being blocked.

Most of the data breaches that were found (some are still live breaches as of publishing) are caused by a sloppy and dangerous growth hack that is used to improve attribution tracking for analytics tools and used to optimize and segment retargeting advertising campaigns.

Several of the breaches involve “plain text” user emails — this is when you can literally read the email in the URL with minimal changes/encodings.

Some of the breaches involve a form of plain text known as “base64 encoding” — in short, base64 is a programming language feature that is NOT a form of encryption and provides no user protections. A base64 string can be decoded through many tools, and there is even a free service from the s̶p̶i̶e̶s̶ nice folks at GCHQ called CyberChef for parsing custom base64 encodings.

Before I get into the details about how this breach happens, and the specific circumstances surrounding the examples, I want to briefly acknowledge and give credit to the team at Wish.com for how quickly they changed their entire email architecture after being informed of their breach — in less than 72 hours Wish had completely rebuilt their email architecture and they had built a completely new auto-login flow via email.

I believe the Wish.com breach was the largest out of all the examples in this research, and it lasted over a year and likely involved hundreds of millions of user emails in a base64 plain-text format being shared with analytics and advertising companies, but their work to quickly escalate the problem, realize the scope, and then pull the trigger to rebuild their systems was a dramatically better response than how other organizations handled these reports. I believe Wish and all organizations in this research should be requesting deletion of user emails from any 3rd party logs held by external advertising and analytics companies, but it appears no organization has submitted this request to their partners, even after being notified of their breaches.

For the most part, most of these user email data breaches are still live as of publishing this research — and in this research I’ll show you how to “breach yourself” by just using current website signup flows and other normal website features on the specific websites in question.

I also want to thank Eliya Stein at Confiant.com for being a sounding board on these technical issues, and helping to provide an additional vet and other important context around the Wish.com breach (those details below).

from Hacker News https://ift.tt/2W8WVAV