Google Analytics is a free software provided by Google to help publishers measure the traffic from other sites to their own sites. Google analytics is how site owners understand how site visitors are interacting with their site.
It’s commonly used to track advertising related traffic in order to know where a campaign is generating more income than is being spent to advertise.
The way that attackers steal user information is by adding their own Google Analytics code into the website, exploiting Google Analytics to send the code to them.
Content Security Policy Header Flaw
Security headers are a way to secure a website against attacks like cross site scripting and script injection, to help stop data theft attacks.
One of these security headers is called a Content Security Policy (CSP) header.
The CSP header tells a browser which domains are trusted for downloading scripts. This keeps a hacker from downloading viruses from another website onto a site visitor’s browser.
According to a report in The Hacker News, the flaw in the CSP header is that on sites that use Google Analytics, Google Analytics is specified in the CSP as a trusted source of scripts.
Thus, because Google Analytics is a trusted source, the hackers are able add their own Google Analytics code to websites and bypass content security protocols.
The Content Security Policy is powerless to stop it.
Developer Mode Cloaking
A quirky thing the hackers are doing is hiding the code when a browser is in Developer Mode. Presumably the hackers are assuming that a site publisher will be inspecting their site for rogue code while the publisher’s browser is in developer mode.
If you’re checking your site to see if there’s an issue, be sure your browser is not in developer mode.
What You Should Do
One way to know if your site is affected by this hack is to check if more than one Google Analytics code is on your site.
In the event that a sites Google Analytics code was completely replaced then that would be noticed because the analtyics would be reporting no traffic.
Removing the rogue analytics code is not enough though. If that code exists then that may mean there’s an underlying vulnerability on the site that allowed the attacker to place the rogue code in the first place.