Earlier this month, it was reported that over 4,200 government and commercial sites in the US and UK were infected with cryptomining malware. The sites hadn’t been compromised by attacks on their servers or content management systems. Instead, Browsealoud, a utility used by all affected sites was targeted. Browsealoud is an accessibility tool that gives websites the ability to read content out loud.
At the time of writing, it isn’t clear how the malicious code found its way into Browsealoud, but once it was injected, every visitor to sites that used Browsealoud — it is to be found on many government and corporate sites — downloaded and executed the code.
In this case, the malicious code loaded Coinhive’s Monero miner, which uses the resources of site visitors’ machines to mine for the Monero cryptocurrency. Mining cryptocurrency at scale usually requires a large investment in high-power hardware. An alternative to buying expensive mining machines is to distribute the work among thousands of lower-powered machines, which is exactly what the Browsealoud attackers hoped to achieve.
Having your computer’s resources wasted to fill an attacker’s Monero wallet isn’t good, but the malware payload could have been much worse. The same technique can be used to inject malvertising, keyloggers, spyware, botnet software, and anything else the attackers deem useful.
Today’s web wouldn’t function without code from third-parties. The vast majority of the sites you visit pull in code from content distribution networks, analytics platforms, and a multitude of other sources. Popular projects like Browsealoud are prime targets for online criminals: compromise one project and you gain access to thousands or millions of users.
Unfortunately, it’s next to impossible for site owners to thoroughly vet every line of code their sites rely on. However, there are security precautions that will reduce the chance of a successful supply-chain attack. Subresource Integrity (SRI) is a security feature built into browsers that sites can use to check the authenticity of code they load from third-party sources.
To use SRI, site owners provide a cryptographic hash of the file to be fetched by the browser. The browser generates a hash of the fetched file and compares it to the hash provided by the site; if the hashes match, the content can’t have been tampered with. None of the sites affected by the Browsealoud attack used SRI.