The malware uses site visitor CPUs to mine for Monero cryptocurrency. The sites that use Browsealoud included the UK Information Commissioner’s office, UK National Health Service websites, an Australian provincial government website and many more.
Texthelp is the company that makes the Browsealoud plugin. They are reporting that their product was infected for four hours, affecting sites that use the Browsealoud plugin before it was take offline. The product remains offline while they investigate.
Cryptomining Attacks On The Rise
In November we wrote about a WordPress plugin that was banned for including cryptomining code, specifically CoinHive code that mines Monero currency. In that case, if a website used the banned plugin, any visitor to the site would see their browser CPU resources exploited to mine Monero and the proceeds were aggregated using CoinHive and sent to the plugin owner. Back then I included a video showing how CPU fan speed increases as the workload increases from Monero mining.
In December of last year, we wrote about a massive Monero cryptomining attack campaign that targeted WordPress.
Scott reports that this campaign also used CoinHive code to mine Monero and send the proceeds back to the attacker.
Supply Chain Attacks Have Wide Impact
On January 2nd of this year, my colleague Dan Moen wrote about the emerging threat of supply chain attacks. He had mentioned to me that, in light of the rise in supply chain attacks we saw in 2017 targeting WordPress, it is quite likely that 2018 is going to see a large number of these kinds of attacks affecting site owners and we had better get the word out, which we did.
As Dan wrote in January, “In the software industry, a supply chain attack exploits a trusted relationship between software vendors or authors and their customers.”. In that post we were focused on discussing the risk of compromised plugins affecting thousands of WordPress sites.
In the case of Browsealoud, the incident could have been much worse. The attacker could have stolen credentials from government websites in multiple countries. Instead, they simply exploited the CPU resources of site visitors to mine Monero cryptocurrency.
How To Protect Your Site and Site Visitors From JS Supply Chain Attacks
Normally you’ll include a script like this:
To secure your site against JS supply chain attacks, change it to:
Making this change is easy. You can visit this page to generate a hash and the inclusion code from a script URL.
The ‘integrity’ attribute contains a ‘hash’ that uniquely identifies the content of the script. If that content changes, the browser can recognize that it has changed and will refuse to load the script. This gives site owners back control over what they load from remote servers, by refusing to load code that has changed from the original version.
Some legacy vendors may rely on the ability to update their code at a URL whenever they please and have your site simply load the new code without you taking action. If a vendor includes a version number in the script URL, as in the jQuery URL above, then you probably don’t have to worry about this. But if the URL is something like //example.com/source/code/lives/here.js and there is no version specified, then check with the vendor to find out whether they will be updating the script you are using. They may need to notify you when they perform updates to avoid service interruptions.
In general I would avoid any vendor that insists on the ability to remotely update code without you making a change to your website code. It’s a security risk, as this case illustrates.
The thing that differentiates a JS supply chain attack from other forms is that, once the attacker installs their malicious code, victims are instantly affected. No action is required by the site administrator or site visitors. Code is being loaded per visit from the compromised server and the moment a code change is made, it is active in victim browsers.
This is different from application supply chain attacks or WordPress plugin supply chain attacks. An application supply chain attack needs a compromised application to be distributed before it exploits users. Desktop or mobile users need to upgrade to the new version before they are effected. Even if an auto-update is pushed out by the attacker somehow, there will be some delay before it is effective.