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.

Thecyber-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.

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.


StatCounter fingers cache-poisoning caper for Bitcoin-slurping JavaScript hijack
Internet be nimble, internet be QUIC, Cloudflare shows off new networking shtick READ MORE

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.

Sponsored: Following Bottomline’s journey to the Hybrid Cloud

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

代码区博客精选文章
分页:12
转载请注明
本文标题:StatCounter fingers cache-poisoning caper for Bitcoin-slurping JavaScript hijack
本站链接:https://www.codesec.net/view/611204.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(80)