Just one of the many folks who shared their “mkt_tok” token inadvertently.

Over the last 2 months, Facebook has quietly changed several ways they deploy Adobe’s Marketo email software across core Facebook marketing programs and websites in order to reduce the impact of a one-token-user-authentication user data vulnerability. But Facebook also continues to send Facebook users emails on a daily basis containing one-token-user-authentication vulnerabilities, and they continue to host websites and signup forms that are vulnerable to targeted user data scraping.

All of the links in this December 2018 Facebook for Developers Newsletter exposes a “mkt_tok” one-token-user-authentication URL variable in the final resolved URL. In numerous Facebook newsletters, Facebook links their users to 3rd party websites that trigger javascript pixels for 3rd party companies who capture the full URL, including the private “mkt_tok” user token appended to the URLs. Facebook also sends users to domains they control like F8.com, which passes the user URL and private token to the advertising networks for Google, Twitter, and Linkedin. Users also inadvertently share their own tokens, sometimes on Facebook.

Facebook’s user data vulnerabilities have existed for over a year, and there are Adobe Marketo forms built in 2017 that are still hosted on Facebook’s domains. These web pages and the ongoing Facebook email strategy make it possible for a Facebook user to share a URL that can be used to expose their email address and other private user information.

One important caveat to this user data vulnerability is that it *does not* impact normal Facebook user accounts that are used by the ~2 billion people (newsfeed, messenger, ads manager, etc.). This user data vulnerability merely impacts the “Shadow b2b Facebook User Accounts” built by Facebook and hosted by Adobe’s Marketo email software that Facebook uses to engage industry experts and encourage them to utilize Facebook tools, and then more recently the vulnerability was extended to Facebook Workplace users due to a deep integration between Facebook Workplace and the Adobe Marketo email software.

One additional caveat, Facebook has been notified about these user data vulnerabilities via their Whitehat disclosure program in a thread with me containing over 30 messages, initially started on October 29, 2018.

Facebook acknowledged the insecurities in Marketo in plain English on December 3, 2018, by writing “at this time sharing those links is not recommended,” but have continued to send out the links to users via email on a regular basis, and have kept dozens of other web pages hosting Marketo forms active that facilitate the data scraping vulnerability. Unfortunately, both sides of this user data vulnerability equation are active and ongoing.

Facebook has since closed the whitehat thread with me, marked it as “Informative” but have kept huge portions of the vulnerability active and ongoing. Due to Facebook’s lack of remedy and ongoing actions, it seemed important to disclose this to users so they can protect themselves. I let Facebook know I was going to disclose this via a public post and sent them one more update this week.

All of the links in this Facebook for Marketers “Facebook IQ” December 2018 Newsletter exposes a “mkt_tok” one-token-user-authentication URL variable in the final resolved URL. If any of these URLs are shared publicly after a user visits them, that user is publicizing a token that can expose their private information.

Finally, Adobe was notified and confirmed receipt of this user data vulnerability existing in Marketo on September 25, 2018 (more on this and screenshots of the conversations below), more than a month before they completed the acquisition of Marketo on October 31st, 2018 and have taken no visible steps since then to alert clients to ongoing user data vulnerabilities or fix these foundational problems in their Marketo software.

This blog post is going to largely focus on Facebook’s deployment of Adobe’s Marketo email software, and why due to Facebook’s internal marketing team’s needs to “move fast and break things” and their need to flexibly control external email newsletters, a feature that (for some reason) doesn’t currently exist within Facebook’s tech stack, their reliance on Marketo created vulnerabilities across different Facebook divisions, external programs, and VIP user bases containing high-spending ad buyers and Facebook platform developers.

Unfortunately, by disclosing this one-token-user-authentication user data vulnerability, it also puts other Adobe Marketo clients at risk of targeted data exfiltration — but Adobe has experience fixing this problem with their own Adobe Marketing Cloud software (I disclosed a similar problem to them last Spring, more below on that too), and Adobe needs to take the same steps with their new acquisition Marketo.

Unfortunately for Adobe, it may be more complicated to deploy two-token-user-authentication within a legacy data architecture like Marketo due to Marketo’s heavy-reliance on one-token-user-authentication. Marketo uses the same user token to both track email opens and clicks, and also uses that same exact token to control updating and accessing user preferences and contact information. “One user token to rule them all,” if you will.

All of the links in this December 2018 Facebook for Business Newsletter exposes a “mkt_tok” one-token-user-authentication URL variable in the final resolved URL.

In short, this vulnerability exists due to a string of text, a variable called “mkt_tok” — this string of text is 23 alphanumeric characters — it’s appended to the end of website URLs by Marketo’s email software after a user clicks a link in an email sent to them by a Marketo client.

That “mkt_tok” token controls both read/write access to the user data, and it also tracks the email opens/clicks. The “mkt_tok” user token is shared from Marketo’s email software, and it seems that nearly all email newsletters sent through their platform have this user token appended to URLs. This means that anytime Client A shares Website B with User C, if that user clicks to visit the website, the user token will be appended to the URL and Website B will see this private one-token-user-authentication variable in all their server logs and analytics tools — and that user token is also shared across the data supply chain to dozens or hundreds of advertising and analytics companies on some popular websites.

On multiple occasions, Facebook sent newsletter emails to their users that linked the user to a 3rd party website, while also appending the users private “mkt_tok” to the URL after clicking the link in the email, and in milliseconds of a user clicking an email, their private user token would pass to the 3rd party website and any advertising and analytics tools that are fired on that domain that grab the final resolved URL.

This one-token-user-authentication leak also occurs when a user clicks to visit a web page, has their user token appended to their URL, and then shares that blog post or page they are visiting publicly — like by writing a public post on Facebook. This is the most common way that Facebook’s VIP users are exposing themselves, and it starts with them sharing Facebook Marketing and Developer news that they were sent via email from Facebook, back onto Facebook. This full loop of “promoting Facebook content on Facebook” exposes a users “mkt_tok” token publicly in the URL they share.

And unfortunately, Facebook also still lets any user search Facebook to look for public posts that contain the URL variable “mkt_tok” (as does Google) — so these user tokens are widely available in public locations. Facebook was notified about these issues but made only minimal changes before closing the issue, so it seems important to alert my fellow marketers and developers to this vulnerability so they stop sharing links sent via these Facebook programs. Facebook Workplace users should also be warned, due to the inclusion of these tokens in new-user Facebook Workplace onboarding email campaigns sent by Facebook.

This email from Facebook is safe. Facebook sends Developer email updates for new blog posts, and these are sent securely using Facebook’s simple email tool. The links in these emails *do not* contain any tokens or user data vulnerabilities.

Finally, this blog post will briefly touch upon the dangers of one-token-user-authentication, why user tokens are rightfully-protected in both Europe’s user privacy framework known as GDPR but also the more-recent California Consumer Privacy Act (CCPA), and also will briefly critique the general concept of “auto-fill forms” and the need to treat them much more like a pseudo-user-login forms than some sort of marketing growth hack, which got Facebook into this mess in the first place.

Without further adieu…