StatCounter web analytics script poisoned to steal Bitcoins

Even if you don’t run your own website, there’s a good chance you’ve heard of Google Analytics. It’s a service provided by Google which helps webmasters determine how much traffic their website is receiving, where it originates from, and so forth… All you have to do is add a couple of lines of code to your webpages, and Google does the rest.

Google may be the most famous, but it isn’t the only web analytics platform out there. One competitor is StatCounter, which can provide its own medley of fancy reports for any website owner who wants to drill down into their traffic.

Statcounter report

All isn’t rosey with StatCounter, however. This weekend researchers at ESET discovered that hackers managed to compromise StatCounter and change the analytics script used by hundreds of thousands of websites.

The researchers determined that the code was altered to intercept Bitcoin transactions made on the Gate.io cryptocurrency exchange (which itself was using StatCounter’s script) and redirect the digital money into a wallet under the hackers’ control.

Unobfuscated code

What’s somewhat bizarre about this is that although compromising the StatCounter script would have run the hackers’ code on potentially millions of computers, it seems it was only Gate.io that they were interested in.

Gate.io’s administrators have since said that they have removed the malicious script from their site. In their statement Gate.io says that it encourages users to harden their accounts with two-factor authentication. That’s not bad general advice, but would have had no impact on how this particular attack was designed to steal cryptocurrency.

This incident reminds me somewhat of an attack earlier this year which impacted many many more websites. Malicious hackers were able to tamper with a widely-used service called “BrowseAloud” which helped make websites more accessible to visually-impaired internet users. After being meddled with, however, BrowseAloud also carried within it cryptomining code which could gobble up the resources of visiting computers.

In an unrelated incident, a similar supply-chain security failure resulted in personal information and payment details being stolen from customers of Ticketmaster after it embedded on its checkout page external code from Inbenta, a technology company that provides online chatbot and support ticketing services.

As I’ve said before, whenever you use someone else’s code on your website you are often increasing your attack surface. Clearly in this latest case the attackers thought it was easier to target a third-party script used by the Gate.io cryptocurrency exchange than hack Gate.io itself directly.

At the time of the BrowseAloud incident, the NCSC offered some great advice for website administrators on how to protect against these type of threats. I think it’s worth repeating:

  • Make a risk-based decision on including third-party JavaScript in your site. This will vary depending on the size of the website you manage and who is supplying the code. Consider whether the code you are including could compromise your users, and balance this against the risk of this happening for your site.
  • If practical to do, consider hosting the JavaScript locally on your own server rather than linking to code hosted elsewhere. This means changes to the libraries require access to your server, although this will mean you will need to install security patches yourself.

In certain cases, some technical measures can also help prevent inclusion of compromised third-party resources:

  • SRI (Sub-Resource Integrity) allows the browser to check a cryptographic hash of the script to ensure that your users are running the unaltered version. However, SRI will only work if the script is relatively static. If it changes regularly, the signature will no longer be valid and the script will not be loaded by users. Also, browser support for SRI is not universal.
  • CSP (Content Security Policy) allows you to whitelist locations where scripts can be loaded from. Several independent researchers have written that having a well-defined CSP in place would have blocked this attack.

More technical details about the StatCounter attack can be found in ESET’s blog post, and you can learn more about CSP and SRI on Scott Helme’s website.

About the author, Graham Cluley

Graham Cluley is a veteran of the anti-virus industry having worked for a number of security companies since the early 1990s when he wrote the first ever version of Dr Solomon’s Anti-Virus Toolkit for Windows. Now an independent security analyst, he regularly makes media appearances and is an international public speaker on the topic of computer security, hackers, and online privacy.

Follow him on Twitter at @gcluley, or drop him an email.

Follow @gcluley