Browsealoud developer Texthelp has taken the service offline temporarily while it works on a fix. The exploit was active for four hours and Texthelp had been preparing for such an attack for a while, CTO and data security officer Martin McKay said in a statement.
“Texthelp has in place continuous automated security tests for Browsealoud, and these detected the modified file and as a result the product was taken offline,” he wrote. “This removed Browsealoud from all our customer sites immediately, addressing the security risk without our customers having to take any action.”
No customer data was compromised or lost, and an investigation is underway, according to McKay. A list of the affected websites, which stands at 4,275, is available here.
The infection was first reported by security researcher Scott Helme. A friend of Helme’s told him that his antivirus software was issuing a warning when he visited the site of the U.K. Information Commissioner’s office, prompting Helme to investigate.
“They’re the people we complain to when companies do bad things with our data,” Helme wrote. “It was pretty alarming to realize that they were running a crypto miner on their site, their whole site, every single page. … I quickly realized though that this script, whilst present on the ICO website, was not being hosted by the ICO, it was included by a 3rd party library they loaded.”
That turned out to be Browsealoud, which had been compromised by attackers that altered one of its hosted JavaScript files, Helme said.
“This is not a particularly new attack and we’ve known for a long time that CDNs or other hosted assets are a prime target to compromise a single target and then infect potentially many thousands of websites,” Helme added.
The attack could have been averted if the sites had employed a simple technique called subresource integrity, Helme said. This tells web browsers to run an integrity check on anything being loaded from a third-party source.
Helme explained the technique in a previous blog post.
“By embedding the base64 encoded cryptographic hash digest that we expect for the asset into the script or link tag, the browser can download the asset and check its cryptographic hash digest against the one it was expecting,” he wrote. “If the hash of the downloaded asset matches the hash that we provided, then the content is what we were expecting to receive and the browser can safely include the script or style. If the hash doesn’t match then we know we can’t trust the data and it must be discarded.”
Source: ThreatPost
