Cryptomining Supply Chain Attack Hits Government Websites
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.
Do you recommend using the integrity code with fontawesome, analytics etc? Or are these safe to use?
Also say we add this integrity code when using the js, and if they update it will it stop working or would it give some kind of warning?
Will it be possible for you'll to add this to your plugin and on first time acan automatically add the integrity code and then later from the plugin itself allow us to regenerate the code of the js has changed.
Great questions. I'm actually having a conversation on twitter about this with Scott. Tough problems. If you use the code, you lose dynamic vendor updates. Thread is here: @mmaunder
Question 1: Ask the vendor.
Question 2: Yes it will stop working.
Question 3: We are giving this some thought.
Whilst I understand the threat and how it works. How do I know when these JS scripts are run, and what kind of things do they bring to my browser...
Make sure you trust them when you install. Once installed, you can use SRI to lock them down and they won't be able to change. However, see my comments to another commenter about the fact that you then prevent the vendor from dynamically updating the script. So check with them to make sure you can lock their script down.
That's very important to know, thanks. I take it that it doesn't affect scripts that you write or have copied from elsewhere, only ones that are present as part of a plugin or program coming from elsewhere?
It affects all scripts. Anything served from a web server can be compromised and if you don't control the script and it comes from an outside source, if you can you should lock it down.
I know I am a nerd because this was fascinating! To SRI or not to SRI? Well as they say when it comes to trusting anyone/anything, trust but verify.
Is there a way to have two allowable SRIs? One for the current release and one for the next release? This would depend on the vendor sending this out before the update, but that small process change would ensure only trusted code. I suppose an SRI go-live timer could control this....
I really do like that vendors can patch/optimize/improve their supply chain based scripts without manual effort from me, but the trade off is clear. This is probably my inner couch potato...
Thanks for another great article!
Interesting thought. The problem is that the vendor doesn't know what a future release's code would look like so it's not possible to compute the hash.
But you've got me thinking. Having the vendor use offline developer keys to sign the code is an interesting idea.
Thank you for this article. I just learned what blockchain and crypto-mining are in the last 2 weeks thanks to a continuing education class. I was wondering how to determine if any of my WordPress sites are using external scripts so I can add SRI if necessary?
Just view source and search for `