Select Page

Here’s a short video explaining the scope of this vulnerability and my initial test:

I recently came across a website that I won’t name that had a very interesting problem — certain pages had almost no 3rd party javascript firing, but they had dozens of javascript pixels hardcoded and the pages were setup to fire additional javascript via tag managers.

Something was broken, but it was broken in a weird way…

A few javascript pixels *were firing* and firing without any errors.

After refreshing the page a few times and trying to debug a few things, I realized that somehow one pixel hardcoded into the page was generating a series of very specific errors that kept the other 3rd party javascript from firing.

At first I assumed it was some sort of developer error — an un-closed <script> tag or something silly that maybe I’d be able to see.

That wasn’t the case… the javascript was extremely obfuscated and I could tell they were up to something odd… unique… potentially malicious…

That website got me thinking… what *is* advertising attribution fraud? How does one party defraud another party through analytics attribution via Javascript errors? Is that possible? Do malicious actors actually do that? Maybe…

If you convinced a client to let you fire/hardcode your pixel on their webpage, could you inject a script that would manipulate conversion data? Even if sending data to the same systems? Could you send javascript that looked like spaghetti-code *but with trusted domains only* to another developer for deployment?

Could you block someone’s Facebook pixel half of the time and show your Facebook pixel all the time, so that you could point to an attribution number showing more conversions from “your ads” even though it was just a hidden pixel error? Could you do that with Google Analytics? Could you embed a Google Analytics script that could block the default Shopify Google Analytics script so that only yours fires and with no errors shown in the Google Tag Assistant Chrome plugin?

I wanted to see about that last scenario, since I use Shopify to run this website and I use Google Analytics … and would prefer an app developer didn’t hijack my data…

The first thing I needed to find was a good Javascript obfuscator with tons of options, because I assumed it was going to take awhile to find something that “breaks right” — I stumbled across the popular opensource Javascript Obfuscator Tool from Timofey Kachalov @ https://obfuscator.io/

The first step is to drop the Javascript you want to obfuscate into the tool:

The second step is to basically choose how much you want to obfuscate the code and how you want to do it — this is the part that really took a bit of time, and I’m not ready to share my settings because I’m still trying to understand the scope of this problem. But the default settings look like this and you can play around with it in tons of ways:

After a series of tests, I was able to get the hardcoded pixel to fire, while breaking the Shopify Google Analytics pixel added in the admin area, and also preventing any errors in the Google Tag Assistant Chrome extension.

The last point about preventing errors in a popular debugger tool is important — a lot of analytics and privacy professionals use the same tools — Ghostery, Google Tag Assistant, Facebook Pixel Checker, etc. But if you can prevent the error from being generated, it’s much harder for those people to find the problem. Here’s what the pixel hijack looked like ƒrom the debugging side:

The Google Tag Assistant Chrome extension is a great example of how this could impact a debugger because the extension icon has a little number next to the URL bar telling you how many Google pixels are firing. Someone who spends a lot of time on their own website optimizing their data layer would get used to seeing a certain number of those pixels whenever they test, and it’s unlikely they would know their Google Analytics property/account ID by memory. So a quick glance at the enabled Google Tag Assistant extension, without the bright red “error” icon, could easily pass muster.

I haven’t seen many articles about “breaking javascript advertising pixels purposefully” or “advertising attribution fraud through Javascript obfuscated on-page blocking” but I think there is the potential to abuse this in some way, and it’s possible some malicious actors are already doing something like this.

After the tests today, I suddenly trust my favorite data layer Chrome debugging extensions a little less…

Here’s a sample of what the obfuscated Google Analytics code looked like from the test (and a normal Google Tag Manager snippet below it):

Have you seen this before? Send us an email at spaghettiJS@victorymedium.com with any details or just to chat about broken Javascript.🤖