Earlier today it was discovered that a large number of websites (over 4,000) – including UK government and NHS websites – had been compromised with a “cryptominer”.

A cryptominer is a piece of software that “mines” cryptocoins like Bitcoin, LiteCoin, Ethereum, etc, which in turn generate income.

When a cryptominer is included within the code of a website and a visitor visits a web page on the site, his/her web browser becomes a “miner” and their device’s CPU is used to “mine” coins for whoever placed the cryptominer within the code.

Essentially, someone else profits at your expense (and at the detriment to your device, if its CPU is being maxed out through mining), and all this takes place without your knowledge!

The large number of sites that compromised today all had one thing in common; they were using a 3rd party service called “Browsealoud” by Texthelp Ltd.

Browsealoud purports to make websites which use it “more accessible with easy speech, reading and translation tools“.

Using browsealoud on a website is as simple as including a single javascript file – hosted on browsealoud’s server – within the code of your pages:

– which is what all sites affected had previously done…. the problem was is that this 3rd party “ba.js” javascript file that webmasters were injecting into their websites in order to make them “more accessible with easy speech, reading and translation tools“, has recently been compromised.

It’s most likely that Texthelp Ltd “browsealoud.com” server’s themselves had been hacked/breached or in some other way compromised, with the criminals modifying the contents of the ba.js file in order to server a cryptominer (coinhive) instead of the file’s original content.

Now a single cryptominer running in a single web browser isn’t all that efficient – it may take weeks to mine just a few coppers worth of coins, but from the criminals point of view, if they were able to have a cryptominer installed on hundreds of different websites, each of which have thousands of visitors, there could therefore be potentially hundreds of thousands of individual cryptominers running and all generating a significant income for the cyber criminals!

Here’s an example of a compromised website, the UK Information Commissioner’s (ICO) Website.

The red text near the bottom of the screen indicates that a resource from the “coinhive” website (the cryptominer) has been blocked (by the browser’s ad blocker), and that this resource was called for by browsealoud’s “ba.js” file included within the code for the ICO website.

When the ICO were made aware of this, they immediately took their website offline. It remains offline at time of writing.

The browsealoud website is also currently offline.

No press statement has yet been released by Texthelp Ltd (the company behind browsealoud), but the company have indicated that one will be released tomorrow (12th Feb).

In the meantime, the UK’s National Cyber Security Centre (part of GCHQ) have released a statement on today’s events, which perhaps suggests that the browsealoud website has actually been forcibly taken down by UK law enforcement, rather than voluntarily taken offline by Texthelp Ltd themselves. This is speculation, however DNS records indicate that the browsealoud.com domain is now pointing to a different IP address than it was prior to today.

As a webmaster what can I do?

There are a couple of things….

Firstly, Webmasters could have easily avoided being caught up in the browsealoud compromise by simply implementing Subresource Integrity (SRI).

Here’s an example of including an external Javascript file in your webpages without SRI:

…and now with an SRI:

The “integrity” attribute of the script tag essentially contains a “check sum” of the contents of the javascript file you wish to include.

When your browser encounters this, it calculates the checksum of the javascript file the website is trying to load and compares this with the checksum the webmaster has provided in the “integrity” attribute. Provided the two match, the resource is loaded. If the two don’t match (i.e. the contents of the .js file have changed from what they were originally – as this will have a different checksum), the resource is blocked by the browser.

Had webmasters injecting the browsealoud “ba.js” file into their websites included an “integrity” attribute in their code, then their websites would have been protected from the browsealoud server compromise and their own websites wouldn’t have subsequently served a cryptominer to visitors today!

So the lesson is; Any webmaster who is including 3rd party resources within their pages should be using Subresource Integrity (SRI) to ensure the content of the resources they’re including is as intended.

If the vendor of the 3rd party Javascript library you’re using on your site doesn’t provide you with a corresponding SRI ‘integrity’ hash to use, you can generate one using websites such as srihash.org.

Secondly, don’t rely on external 3rd party scripts running on your site in order to “improve accessibility” – code your sites to be accessible in their own right!

As a hosted tool/library/service provider what can I do?

If you’re a provider of tools/libraries/services that webmasters can include within their own websites with a line or two of code – such as browsealoud – make sure that in the code snippets you provide to webmasters, you include Subresource Integrity checking!

As an internet user, what can I do?

The best way to protect your device from browser-based cryptomining is to use an “ad blocker”, as these now block known cryptomining software such as coinhive.

UPDATE:

Texthelp have now released a statement claiming that following the breach of their systems at 11:14 today their “automated security tests detected the modified file and as a result it was taken offline“. Strange, as it was still online at 3pm, and seemingly only taken down after a number of researchers like myself & others brought it to their attention! Texthelp were seemingly unaware of the problem before that!