they include The City University of New York (cuny.edu), Uncle Sam's court information portal (uscourts.gov), Lund University (lu.se), the UK's Student Loans Company (slc.co.uk), privacy watchdog The Information Commissioner's Office (ico.org.uk) and the Financial Ombudsman Service (financial-ombudsman.org.uk), plus a shedload of other .gov.uk and .gov.au sites, UK NHS services, and other organizations across the globe.They were all running Coinhive's Monero miner in visitors' browsers. How and why did this happen and what should these sites have been doing to prevent it? Follow me below the fold.
Manchester.gov.uk, NHSinform.scot, agriculture.gov.ie, Croydon.gov.uk, ouh.nhs.uk, legislation.qld.gov.au, the list goes on.
|Some resources for a page|
In an age in which every browser gifts a free-to-use, unlimited-usage, fast VM to every visited web site, and these VMs can boot and run quite responsive 3D games or Linux distributionsYou (and I) need to be very careful about gifting these VMs to sites we don't trust, which is why I use NoScript. The resources Talking Points Memo wants me to execute are not delivering me information I want. A few of them want to show me ads, probably for things I just purchased and so will definitely not purchase again. Most of them want to track me. Back in 2015 Georgis Kontaxis and Monica Chew won "Best Paper" at the Web 2.0 Security and Privacy workshop for Tracking Protection in Firefox for Privacy and Performance (PDF). They demonstrated that Tracking Protection provided:
a 67.5% reduction in the number of HTTP cookies set during a crawl of the Alexa top 200 news sites. [and] a 44% median reduction in page load time and 39% reduction in data usage in the Alexa top 200 news site.Some of them would likely have been malvertising, using the incredibly complex and opaque advertising ecosystem as an efficient channel for distributing malware. But increasingly, as in this case, some of them would be cryptojacking, mining cryptocurrency in your browser. It turns out that, although the return from an individual browser is small, as Brannon Dorsey demonstrated it is easy to collect vast amounts of computing resource by advertising:
So that's what Dorsey did -- very successfully. Within about three hours, his code (experimental, not malicious, apart from surreptitiously chewing up processing resources) was running on 117,852 web browsers, on 30,234 unique IP addresses. Adtech, it turns out, is a superb vector for injecting malware around the planet.
Some other fun details: Dorsey found that when people loaded his ad, they left the tab open an average of 15 minutes. That gave him huge amounts of compute time -- 327 full days, in fact, for about $15 in ad purchase.
The affected sites all use a fairly popular plugin called Browsealoud, made by Brit biz Texthelp, which reads out webpages for blind or partially sighted people.Plugin, library, same difference. They're both code from some place else that the page invokes. On Twitter, Prof. Alan Woodward points out what sites should have been doing to prevent this:
This technology was compromised in some way – either by hackers or rogue insiders altering Browsealoud's source code – to silently inject Coinhive's Monero miner into every webpage offering Browsealoud.
This is what happens when you use third party content & don’t ensure its integrity. Just look at all those public sector sites affected. If you wanna know how to stop it read these:Prof. Woodward and security researcher Scott Helme are suggesting sites need to do three things:
And use @reporturi
here and here. In the context of the live Web, Scott Helme's introduction to CSP explains its use:
Content-Security-Policy: script-src 'self'
But coinhive.com is not actually the problem. The problem is that your browser is running malicious code from browseraloud.com, and that is a site that would have been in the CSP whitelist. The miscreants could have copied the miner code into the browseraloud.com page rather than incorporating it by reference. This is where SRI comes in.
What SRI is intended to do is to prevent Content Distribution Networks (CDNs) altering content they are distributing. Scott Helme explains:
Most sites on the Internet these days load some kind of content from a CDN, usually JS and CSS. Whilst this comes with great performance boosts and savings on bandwidth, we're trusting that CDN to load content into our pages, content that could possibly be harmful. Until now, we had no way to verify the content we were loading from the CDN was actually what we expected, it could have been altered or replaced. SRI allows us to check the integrity of the JS or CSS to ensure it's exactly what we were expecting.How is this done?
SRI allows us to instruct the browser to perform an integrity check on an asset loaded from a 3rd party. By embedding the base64 encoded cryptographic hash digest that we expect for the asset into the script or link tag, the browser can download the asset and check its cryptographic hash digest against the one it was expecting. If the hash of the downloaded asset matches the hash that we provided, then the content is what we were expecting to receive and the browser can safely include the script or style. If the hash doesn't match then we know we can't trust the data and it must be discarded.There are lots of interesting details about the use of SRI that you can read about in Scott Helme's explanation. But what's relevant here is that SRI doesn't just protect your site's visitors from accidental or malicious corruption of content by CDNs, it protects them from compromise of the originators of resources that your site uses such as browseraloud.com. Had the sites co-opted into mining Monero used SRI to force the browser to check the hash of the code from browseraloud.com,they would have discovered that the code had been corrupted and refused to run it.