Small crypto mining attack points to big browser problem

Feb 14, 2018 / 3 min read

Table of Contents

So, threat eliminated, damage minimal – end of story?

As malware attacks go, this one was relatively benign. But that doesn’t mean it shouldn’t be taken seriously.

The criminals who infected an estimated 5,000 or more websites in the US, the UK, Canada, Ireland and Australia starting at 11:14 a.m. GMT Sunday – many of them government sites – were apparently only interested in sucking electricity and processing power from victim computers so they could mine the cryptocurrency Monero.

Their entry point was an accessibility plugin called Browsealoud, offered by a company called Texthelp to assist those who are blind, visually disabled or otherwise have trouble reading. They modified the plugin by injecting malicious JavaScript that was then used to download software from coinhive(dot)com to start mining for cryptocurrency.

Scott Helme, an IT researcher and consultant who was the first to post about the attack, included screen shots on his Twitter thread that showed victims included the General Medical Council, National Health Service and Information Commissioner’s Office in the UK, the US Courts and the Queensland Government in Australia.

But according to a statement issued by Martin McKay, Texthelp’s CTO and data security officer, there was no attempt to extort or ransom money from Texthelp or its customers, no customer data were accessed or stolen, and the whole thing was over in four hours when Browsealoud was taken down.

And since the malware doesn’t “achieve persistence,” all victims have to do to eliminate it is to close their browsers.

McKay added that in light of the attack, “we are strengthening our security systems further.”

So, threat eliminated, damage minimal – end of story?

Not by a long shot, according to Steve Giguere, sales engineer with Black Duck. “There is a larger issue here,” he said. “It’s less about the cryptomining malware and more about how powerful the browser is.”

As in, more powerful but also more vulnerable.

“Over the past 10 to 15 years, the browser has changed from being a passive window onto the Internet to a fully functional multi-purpose application portal with a comprehensive attack surface,” he said.

Which means that not only is the hack of a plugin just one of thousands of possible attack vectors, but it is also more a matter of luck than anything else that the damage wasn’t much worse.

Helme, who investigated after he got a message from a friend whose AV software had detected a problem from a visit to a UK website, told Motherboard that while the only apparent motive of the attackers was to mine cryptocurrency, they had the power and access to do much more, such as installing a keyloggers onto victims’ computers or infecting them with more invasive malware.

“It could have been a catastrophe, it really could have – that’s not just scaremongering,” Helme said.

Travis Biehn, technical strategist with Black Duck, said this kind of attack is not new.

“There’s a long history of attackers compromising popular web destinations, and exploiting those resources for monetary gain,” he said. “The user populations are sometimes more valuable than the data on the compromised service.”

But browsers remain largely unequipped to block or even detect those attacks.

The problem, he said, is, “how does the browser verify that the code it has received from a website is the same code the organization released to production?”

Some threats are filtered by HTTPS, which can prevent man-in-the-middle attacks.

But, Biehn said, there is a much larger attack surface before, or “upstream,” of HTTPS protections.

“Load balancers, upstream enterprise components, which have exploded with microservices trends, and application servers themselves present a pivot point for attackers looking to exploit customers,” he said, “because they can all introduce code before those connections are protected over the wire with HTTPS.”

The solution? It’s not available yet. What is needed, Biehn said, “is an addition to web-standards – one that allows organizations to produce verifiable client-code, and browsers to validate that code.

“To date, the strongest technologies that can be deployed to protect against these attacks are insufficient to actually tackle the problem.”

Helme told Bleeping Computer that websites can protect themselves by using CSP+SRI (Content Security Policy plus Subresource Integrity).

With SRI, the owner of a site specifies a hash for script to be loaded. The browser then won’t load a script that has been modified from that hash.

CSP forces the browser to require all scripts to have an SRI hash associated with them. Any that lack it it will be blocked.

But Biehn said those are not good enough – yet. “These technologies are still in their infancy, and they aren’t comprehensive to a full ‘build’ of a web-application,” he said. “They reduce a small part of overall risk, but they are ultimately significantly insufficient.”

Which means the endless urging of multiple security experts over the past decade and more still applies: Build security in, from the beginning of the SDLC.

“The designers of the plug-in may have underestimated the security requirements of their own SDLC and/or never thought themselves a target,” Giguere said. “Hackers are always looking for a weak link.”