In the past 24 hours, Security researcher Scott Helme discovered that a third party accessibility plugin called ‘Browsealoud’ had their servers compromised. The plugin relies on a website including Javascript in their content in order to work. This compromise resulted in over 4,000 websites serving up cryptomining malware.

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.

This is another kind of supply chain attack that affects the “trusted relationship between software vendors or authors and their customers”. You trust a service distributing Javascript to maintain site security. If that service is compromised, it affects any website using that code – potentially thousands of websites. As is the case with WordPress plugins, Javascript supply chain attacks allow a malicious actor to compromise thousands of websites with a single hack.

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

There is an easy way to protect yourself against Javascript supply chain attacks using a security feature called Subresource Integrity, or SRI. If you are including javascript code from an external source using the <SCRIPT> tag, simply include an ‘integrity’ attribute which will cause browsers to not load the script if it is modified from the original version.

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.

You should be aware that once you use SRI and include a hash for your scripts, if the vendor changes the script, it will not load. This has the benefit of protecting your site visitors if a hacker compromises the vendor site and injects malware into the javascript that you are loading. But it also has the side effect that if a vendor updates their code at that same URL, your script will no longer load.

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.

Javascript Supply Chain Attacks Are Real-Time

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.

A WordPress plugin supply chain attack needs site owners to update to the new compromised plugin version before it is active. Javascript supply chain attacks are instantly active and being loaded by site visitors as soon as the attacker saves the file to the distribution web server. That is why it is critically important to use SRI for all external scripts on your site.

Please spread the word about the risk of Javascript supply chain attacks and how to mitigate them using Subresource Integrity or SRI.