Thousands of sites were injected with a in-browser Monero miner today after a popular accessibility script was compromised. With 4,275 sites affected, this included government websites such as uscourts.gov, ico.org.uk, & manchester.gov.uk.
This was first noticed earlier this morning by infosec consultant Scott Helme when he saw that UK government site ico.org.uk was utilizing the the Coinhive in-browser mining (cryptojacking) script. This caused any visitors to the site to use their CPU to mine for the digital currency called Monero.
When Helme investigated further he saw that it wasn't just this site that started injecting a Coinhive miner, but many other government sites from numerous countries such as uscourts.gov, gmc-uk.gov, nhsinform.scot, manchester.gov.uk, and many more.
The one thing all of these sites had in common was that they utilized a popular text-to-speech accessibility script called BrowseAloud by TextHelp.com. When Helme examined the BrowseAloud script, he saw that this script contained obfuscated code that was injecting the Coinhive miner into all of these websites.
When decoded, this script injects the Coinhive cryptojacking script, runs it at 40% CPU utilization, and mines for the 1GdQGpY1pivrGlVHSp5P2IIr9cyTzzXq Coinhive account.
Knowing that it was a compromised BrowseAloud script that was injecting the miner, Helme was able to quickly track the script to 4,275 sites that were affected in the incident.
After alerting TextHelp.com about their compromised script, the CTO of TextHelp stated that the script was taken down and would not be enabled again until after an investigation took place.
BleepingComputer reached out to TextHelp for more information but had not heard back from them at the time of publishing this article. According to a recently published post by TextHelp, the company has stated that an attacker compromised the BrowseAloud script, but no other TextHelp services were affected.
Helme told BleepingComputer that a good way for sites to protect themselves from attacks like this is to use CSP+SRI.
SRI, or Subresource Integrity, is when a site owner specifies a hash for a particular script that they are loading on a site. Before the browser loads the script, it checks the hash of the script and compares it to the one listed on the site. If it matches, then the script is loaded. If the script has been modified, though, then the script will be blocked from loading.
If you use CSP, or Content Security Policy, you can take it one step further by forcing the browser to require all scripts to have a SRI hash associated with them. If a script does not have an assigned hash, it will simply be blocked from loading by the browser.
Helme has an article on this subject and how to use it for those who are interested.
The only downside with this approach is that it could cause a bit more administration for a web site owner as they would need to keep track of external scripts that they use and when they get modified. If a 3rd party script is being used and is commonly modified, then you will need to make sure to update your SRI hashes for each new update.
While some may not want to deal with the extra work required to securing scripts like this, it is always important to remember that security is hard, but repairing a tarnished reputation is harder.
UK National Cyber Security Centre (NCSC) have also started an investigation into the incident.
This is also not the first incident where a hacked website widget has been used to spread a cryptojacking script. Last November, miscreants compromised the LiveHelpNow live chat widget to deploy Coinhive on 1,500+ sites.