Cryptomining Supply Chain Attack Hits Government Websites

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.

Did you enjoy this post? Share it!

Comments

17 Comments
  • 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.

  • That ability to protect external javascript links is gold dust! I've added it already to a site I'm working on now.

    Many thanks.

  • 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 `

  • Does WP implement SRI for enqueue scripts?
    https://core.trac.wordpress.org/ticket/33948

    • We don't do anything with SRI right now. To be clear, having SRI for local scripts wouldn't help because if your site is compromised all hashes can be recomputed by attacker - in fact they'll just replace the tags with malicious code.

      For external CDN assets it's interesting but will probably break stuff because devs may expect the ability to dynamically update. Unless as I mentioned in the post, a script includes a version and it's locked down and won't change. In that case it's a very good idea to include an SRI tag.

      We may be able to do something like detect your scripts with version tags and do a one time compute to generate SRIs and lock things down. Will give it some thought.

      • In case it's of interest, the free WP-SRI plugin I wrote several years ago automates the process of hashing script and style resources and adding appropriate integrity attributes to your pages. Any JavaScript or CSS stylesheet added with one of the wp_enqueue_*() functions is hashed and remembered (in Trust-On-First-Use style). I haven't updated the plugin in about two years but that's because it still functions with the latest release of WordPress without any problems.

  • Thanks for this info.

  • It seems most of the JS I want to SRI hash is not possible.

    e.g.
    https://www.google.com/recaptcha/api.js
    https://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit

    On report-uri.com it says "The server does not have CORS enabled. This resource can't be integrity checked."

    What do I do in this case?

    • Hi Ian,

      I think you're stuck. Google don't have CORS configured and are probably dynamically updating that script.

      Mark.