Government websites hit by cryptocurrency mining malware

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 United States, the United Kingdom, 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, are visually disabled, or otherwise have trouble reading. The attackers modified the plugin by injecting malicious JavaScript that was then used to download software from the Coinhive website to start mining for cryptocurrency.

Scott Helme, an IT researcher and consultant who was the first to post about the attack, included screenshots on his Twitter thread that showed the victims included the General Medical Council, National Health Service, and Information Commissioner's Office in the United Kingdom, the U.S. Courts website, 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 was accessed or stolen, and the whole thing was over in 4 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 Synopsys Software Integrity Group. "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 multipurpose 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 also the fact that the damage wasn't much worse is more a matter of luck than anything else.

Helme, who investigated after he got a message from a friend whose AV software had detected a problem during a visit to a U.K. 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 keylogger on 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 Synopsys Software Integrity Group, 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, Biehn said, is this: "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's 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's 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 any script to be loaded. The browser won't load a script that doesn't match its hash.

And CSP forces the browser to require all scripts to have an SRI hash associated with them. Any that lack one 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 plugin 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."

Taylor Armerding is senior security strategist at Synopsys.