NCSC advice: Malicious software used to illegally mine cryptocurrency

The NCSC is aware of a compromise of the third-party JavaScript library ‘Browsealoud’ which happened on 11 February 2018. During the compromise, anyone who visited a website with the Browsealoud library embedded inadvertently ran mining code on their computer, helping to generate money for the attackers. No money was taken from users themselves, but the mining code performed computationally intensive operations that were used to earn the cryptocurrency. These operations may have affected the performance and battery life of the devices visiting the site.

Browsealoud was taken offline shortly after the compromise, mitigating the issue. However, website administrators, and other JavaScript library developers may wish to take further steps to prevent future compromise by following the guidance below.

You can also read more about cryptomining in last week’s NCSC Threat Report (published 9 February 2018).

• The cryptojacking harnessed people’s computers to help ‘mine’ for cryptocurrency. This involves using your device to perform computations and does not take any money from you or your accounts.
• The only impact on affected users’ computers was that they temporarily had minor performance loss and reduced battery power.
• If you have experienced unusually slow performance from your computer, reduced battery life, or visited the affected websites we recommend:
  • Closing the browser you visited the webpage on is likely enough to stop the mining;
  • Clearing the browser cache will remove all traces of the code. Guidance on how to do this is available here: http://www.refreshyourcache.com/en/home/

• Make a risk-based decision on including third-party JavaScript in your site. This will vary depending on the size of the website you manage and who is supplying the code. Consider whether the code you are including could compromise your users, and balance this against the risk of this happening for your site.
• If practical to do, consider hosting the JavaScript locally on your own server rather than linking to code hosted elsewhere. This means changes to the libraries require access to your server, although this will mean you will need to install security patches yourself.

In certain cases, some technical measures can also help prevent inclusion of compromised third-party resources:

• SRI (Sub-Resource Integrity) allows the browser to check a cryptographic hash of the script to ensure that your users are running the unaltered version. However, SRI will only work if the script is relatively static. If it changes regularly, the signature will no longer be valid and the script will not be loaded by users. Also, browser support for SRI is not universal.
• CSP (Content Security Policy) allows you to allow list locations where scripts can be loaded from. Several independent researchers have written that having a well-defined CSP in place would have blocked this attack.

We recommend putting the above mitigating measures in place where practical, and while we recognise these will not necessarily protect end users in all cases they will reduce the chances of your website being compromised.

• Implement robust change control for your code, including monitoring your codebase for unauthorised modifications, reviewing code contributions, and having a rapid takedown process in place for if a compromise is detected.
• Where you offer hosted versions of your library, ensure that you have robust access control and logging in place for making changes to the library.
• Consider supporting customers who wish to use Subresource Integrity (SRI). For example, providing numbered versions of libraries which remain static, and so have a static cryptographic hashes will enable customers to validate their integrity.