In recent years, new malware exploits and vulnerabilities have begun occurring on a much larger scale. Typically, the goal of malware is to infect your web browser or take over your computer in order to perform a number of malicious tasks like stealing personal or banking information, or participating in botnets. Recently, Sentrant, an internet security company, has detected a new type of ad fraud that hijacks home network routers and intercepts requests for Google Analytics tags to inject ads and pornography. Because Google Analytics is ubiquitous across the web, these ads would get served on nearly every website visited. What makes this attack even more unscrupulous, is that once the router is infected, all devices that are connected to that router will also display these ads.
What Can You Do?
While we haven’t heard any reports or complaints about this particular issue from our own clients, it is possible that you may have already been exposed to this issue. So, the question is, what can you do about it? Based on the information available on the web, there doesn’t appear to be much you can do to stop these. Ultimately, the root cause lies on the consumer’s side. Because their router is infected, you have no control over any of the components that can make a difference. The only thing we can hope for as an advertiser or webmaster, is that vendors and manufacturers improve their security and default settings, and that consumers are better aware of how to secure their devices.
Detecting Malicious Code
We tried to devise a way to detect if a particular browser is serving up the malicious code file. But since the injected file includes the original Google Analytics script, there isn’t really an obvious telltale sign.
Image credit: Sentrant.com
You could potentially try to detect certain variables or functions that the malicious code injects, but there is a chance that their code could change, which would render your detection methods useless.
Hosting Your Own Code
The way the attack works is that it overwrites the DNS settings, so that all requests for files hosted on www.google-analytics.com are sent to their rogue server.
Image credit: Sentrant.com
Because the loophole is in the DNS lookup, we can bypass this by hosting our own version of the analytics.js library and rewrite the Google Analytics snippet to request the file from our domain instead.
There are however a couple of potential problems that could arise with this approach:
- Every time there is a change in the analytics.js file, you’ll want to update your version as well. This is so that you will continue to receive all the newest features and functionality.
- If you have an SSL-enabled site, you will need to update the code snippet to handle that situation. Especially if your SSL site is not on the same subdomain as your non-SSL site.
While this solution will work, you might want to ask yourself if it’s worth the time spent, when the extent of the problem is still unknown.
