StatCounter fingers cache-poisoning caper for Bitcoin-slurping JavaScript hijack

The good news? Nobody appears to have lost any Bitcoin, says Gate.io

This week's hijacking of StatCounter's JavaScript to swipe Bitcoins from a crypto-coin exchange was the result of a web cache poisoning attack, apparently.

The cyber-heist, in which a malicious snippet of JavaScript code was inserted into StatCounter's tracking script, which websites embed in their pages to monitor visitor traffic, was part of a larger attempt by hackers to intercept and redirect Bitcoin transactions taking place on the Gate.io cryptocurrency exchange.

Fortunately, security sleuths at ESET were able to clock the nasty JS being served from statcounter.com, and reported the caper.Both StatCounter and Gate.io took measures to shut down the attack soon thereafter. Gate.io said that no coins were actually stolen and Statcounter told The Reg a customer reported this to us on Tuesday and it was fixed within a few hours.

But how was the attack possible? StatCounter told The Register that, rather than its servers being directly compromised to sling out bad JS on Gate.io, miscreants poisoned one of its tracking scripts served via its content distribution network, Cloudflare.

This resulted in websites embedding StatCounter code to pull the booby-trapped script from Cloudflare.

What normally happens is this: a website sets up Cloudflare as a cache so that when visitors hit the site, they fetch from the Cloudflare cache instead. This relieves pressure on the website's servers, and makes Cloudflare take the load. But in order to work, the cache has to reach out to the site's servers for copies of pages when they are first requested by visitors, and keeps a copy of these files to serve to subsequent requests.

It's possible to craft requests to the cache such that malicious files are fetched from another server, and not the legit website server, and are stored in the cache so that subsequent requests from visitors fetch the poisoned files from the cache. This is possible using techniques like changing the X-Forwarded-Host header in the HTTP(S) request to pull into the cache an infected file from an evil server.

Cloudflare has been warning of this attack vector for months, but apparently StatCounter had not properly configured their servers and settings to keep an attacker from taking advantage of this weakness.

While StatCounter said it has since shored up its defenses, and removed the compromised code from the cache, the metrics firm is already down at least one customer:

"Following suspicious activity, we have stopped using StatCounter's services," Gate.io told The Register. "No user funds have been removed and we have not seen any irregularities on our platform."

Cloudflare, meanwhile, kept its statement on the matter brief.

"We do not comment on customer configurations," a spokesperson tells El Reg. "We have no evidence of a compromise in our infrastructure."

So there you have it, a potentially catastrophic financial attack appears to have largely been averted and, aside from some lost business for StatCounter, an important lesson was learned with relatively little pain.

Now, go and make sure you have locked down your own cache servers. ®