Cryptocurrency Miners: How to Shield Browsers From Bad Guys
Earlier this week, keen spotters discovered more than 4,200 websites were suddenly delivering cryptomining code to their visitors (see Government Websites Deliver Cryptocurrency Mining Code).
But the websites weren't hacked. Instead, all had simply been using well-intended accessibility software called Browsealoud from Texthelp that helps people with disabilities, such as by reading websites out loud or magnifying text.
Coinhive borrows CPU or GPU cycles from computers to mine a cryptocurrency called monero. Mining is the term for verifying blockchain transactions; it's rewarded with a trickle of cryptocurrency.
Coinhive is intended as an alternative monetization tool to showing advertisements. But Coinhive says publishers, which most recently include the online news site Salon, should inform users that their computers will be used for mining.
Big Coinhive users include porn sites, gambling sites, sites hosting audiovisual content as well as various blogs and forums.
Browsealoud's tool was hosted on Amazon's S3 storage service. Although it's not clear how Coinhive code ended up in Browsealoud, it is possible that someone gained Texthelp's authentication credentials and then accessed the S3 code repository.
"Running a cryptominer was the simplest, most benign thing that could have been done," he says. "We dodged a bullet with this."
The Browsealoud code subversion was a bust. For the four hours that Texthelp's Browsealoud accessibility plug-in contained Coinhive mining code, it generated only 0.1 monero, or $24, Coinhive tells Motherboard. Coinhive says it would normally pay out the money to users, but in this case has withheld the payment to attackers.
So despite managing to sneak cryptomining code onto thousands of websites, even if the attack had gone undetected for longer - say, a week - at $6 per hour, attackers would have only generated $1,000 worth of monero. This does not appear to be a valid get-rich-quick scheme.
Code Mandate: Maintain Integrity
This situation highlights a long-known coding concern: Websites and services constantly call on other code libraries hosted elsewhere, such as content delivery networks, but have little or no visibility into how those services might be protected.
How can you trust those services? Or to put it another way: How do you ensure that if code libraries are tampered with, your users aren't affected?
There are a couple of ways for websites to take steps to prevent damage: subresource integrity is one; content security policy is another. Both are W3C standards.
"Very few people know about SRI and CSP," says Hunt, who has published an in-depth explanation of both specifications. "But we're really in an era now where we've got so many interdependencies on websites that we really need to start doing this stuff because what we saw was just a little taste of what can go wrong."
SRI allows website operators to add an "integrity" attribute to the script tag when it gets embedded into a website's code. Most browsers support SRI, and Microsoft is planning to add it to its Edge browser soon.
The tag contains a hash of the expected script. If someone tampers with the script, it will have a different hash, and the browser will reject the script.
In the Browsealoud incident, subresource integrity would - in theory - have stopped the script in its tracks.
But there's a twist: Browsealoud isn't just a script, Hunt says. It's a dynamic service that is constantly updated and needs to send data, such as the text of web pages, back to Texthelp for functions such as translating. The same scenario applies to other widely used services embedded into websites, such as Disqus, Hunt adds.
In general, subresource integrity works well with applications that have version numbers. But if the version changes, website operators would need to update the integrity tag. Otherwise, the script won't run.
Browsealoud's script is not versioned, so website operators just have to accept its integrity - a dangerous scenario, and one which would allow Coinhive to strike again, if attackers managed to again subvert the code base.
So what do you do?
Finer-Grain Control With CSP
One solution is to create a Content Security Policy, or CSP. This allows much more fine-grained control of the resources a script can call and avoids the all-or-nothing smackdown of SRI.
"It's all about creating a really sort of clear set of instructions over what you can and cannot do," Hunt says.
In other words, CSP is a whitelisting tool. For example, with Browsealoud, admins could whitelist various resources that the tool needs, such as images and other scripts. But they could CSP to block outright all unknown services, such as Coinhive.
"In that situation, all of Browsealoud would have continued to work," Hunt says. "But when it tried to embed Coinhive, the browser would have blocked the request."
Unfortunately, statistics complied by British security consultant Scott Helme show that only 2 percent of Alexa's top 1 million websites have CSP policies in place.
Also, while it's great for sites to set a CSP, the real benefit comes when website operators get notified quickly when the specified policy they set has been violated.
Helme created a subscription service called Report URI, which sends reports about violated security policies, such as CSP or HTTP key pinning, to sites that subscribe.
Website operators quickly get reports specifying the exact page where the violation or hiccup occurred. Report URI will show what code was attempted to be injected and where the code originated.
Hunt, who is an investor in Report URI, says the service collectively amasses 1 billion reports a month.