Monero Logo

Not a week goes by without something else being infected with some form of crypto-currency mining software recently; in December one of Starbucks’ Buenos Aires locations was identified as hijacking customer computers to mine Monero when they connected to in-store WiFi; and YouTube recently remedied a vulnerability that would allow crypto mining scripts to be placed in ads it served. Yesterday it was found that a large number of government websites were found to have been hijacked to serve the Monero mining script, Coinhive.

The exploit was initially spotted by security consultant Scott Helme who first noticed the script running on the ICO website. It wasn’t long before it was noticed that this script was not only running on the ICO’s website, but many other government websites including the Queensland Government website, several NHS websites, and the US Courts website.

Within a short space of time it was found that the source of the vulnerability was a plug-in by Texthelp called BrowseAloud which assists with the accessibility of websites. It was found that this plug-in had somehow allowed another party to discreetly inject their Coinhive script into this plug-in, this meant that any of the websites who implemented BrowseAloud would find their users would trigger the script when they visited one of the affected websites.

This episodes really exemplifies why anyone creating software also needs to consider the security of any third party involved. It was likely noticed by the person who implemented this script that by exploiting BrowseAloud, they could multiply the effect of their vulnerability to what could be thousands of websites; and with the potential of crypto-currencies to rise again in price, the hacker could be looking at a significant return on their investment.

Currently we don’t know how the attacker managed to inject their code into the BrowseAloud plug-in, but the recommendation by Scott Helme was to implement Subresource Integrity which compares the hash of an object loaded to what the website was expecting, which would have mitigated the effect of the loophole this script was taking advantage of (a longer explanation is available on the W3C website). While this script was relatively harmless in terms of affect on a user (no loss of data, simply a loss of processing power while that website was open) the potential for this loophole to be exploited for more nefarious purposes is clear and so it is paramount that third party involvement will need to be kept in mind when designing software.