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 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 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, 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.”