[ad_1]
This week, the hijacking of the StatCounter JavaScript code to let Bitcoin flow from a cryptocurrency exchange was the result of a web cache poisoning attack, it seems.
The cyber-abduction, in which a malicious snippet of JavaScript code was inserted into the StatCounter tracking script, that websites embed on their pages to monitor visitor traffic, was part of a larger attempt by hackers to intercept and redirect Bitcoin transactions that take place on the Gate.
Fortunately, ESET's security officers were able to record the ugly JS served by statcounter.com and reported the caper. Both StatCounter and Gate.io took steps to close the attack shortly thereafter. Gate.io said that no money was stolen.
But how was the attack possible? StatCounter said The register that, rather than its servers were directly compromised to launch JS on Gate.io, the bad guys poisoned one of its tracking scripts served through its content distribution network, Cloudflare.
This led to Web sites that incorporate the StatCounter code to extract the script overflowed by Cloudflare.
What normally happens is this: a website sets Cloudflare as a cache so that when visitors reach the site, they take the Cloudflare cache instead. This relieves pressure on the Web site servers and takes the load to Cloudflare. But to work, the cache must reach site servers for page copies when they are first requested by visitors and keep a copy of these files to satisfy subsequent requests.
Cached requests can be created so that malicious files are retrieved from another server, not the legitimate website server, and cached so that subsequent visitor requests pick up the poisoned files from the cache. This is possible using techniques such as editing the X-Forwarded-Host header in the HTTP (S) request to cache a file infected by an evil server.
Cloudflare has warned this attack vector for months, but it appears StatCounter has not properly configured its servers and settings to prevent an attacker from exploiting this weakness.
Internet is agile, internet being QUIC, Cloudflare showcases the new network shtick
READ MORE
While StatCounter claimed that it has since strengthened its defenses and removed the compromised code from the cache, the metric company has already lost at least one customer:
"As a result of suspicious activity, we stopped using StatCounter services," said Gate.io The register. "No user funds were removed and we did not find any irregularities on our platform."
Cloudflare, meanwhile, maintained its statement on the short question.
"We do not comment on customer configurations," says a spokesperson El Reg. "We have no evidence of a compromise in our infrastructure."
So, here it is, a potentially catastrophic financial attack seems to have been largely avoided and, apart from some business lost to StatCounter, an important lesson has been learned with relatively little pain.
Now go and make sure you have blocked your cache servers. ®
