Fraud Management & Cybercrime , Incident & Breach Response , Managed Detection & Response (MDR)

Cryptocurrency Miners: How to Shield Browsers From Bad Guys

Browsealoud Subversion Points to Larger Trust Issues With Third-Party Code
Cryptocurrency Miners: How to Shield Browsers From Bad Guys
Accessibility plug-in Browsealoud was recently hacked, making thousands of websites use visitors' systems to mine for cryptocurrency. (Source: Scott Helme)

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).

See Also: Gartner Guide for Digital Forensics and Incident Response

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.

Miscreants somehow managed to slip a JavaScript tool called Coinhive into Browsealoud. When websites pulled Browsealoud's code, Coinhive started running in a browser tab. The incident lasted just four hours until Texthelp temporarily shut down Browsealoud, identified the problem and excised the Coinhive code.

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.

News website Salon has begun offering ad-free browsing in exchange for users allowing their system to be used to mine cryptocurrency.

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.

Cryptocurrency mining is a relatively benign kind of abuse, says Troy Hunt, an Australian computer security expert. The JavaScript miner runs in a sandboxed tab and can't interfere with anything else. Once the tab is closed, it stops.

"Running a cryptominer was the simplest, most benign thing that could have been done," he says. "We dodged a bullet with this."

The incident could have been far worse. The ability to run arbitrary JavaScript in a browser session has the potential for far more potent attacks, such as collecting payment card details or stealing credentials from web-based forms, for example for consumers' online bank accounts.

"We dodged a bullet with this."
—Troy Hunt

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.

Report URI

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.

Only 2 percent of Alexa's top one million websites have Content Security Policy in place.
—Source: Scott Helme

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.

Executive Editor Mathew Schwartz also contributed to this story.


About the Author

Jeremy Kirk

Jeremy Kirk

Executive Editor, Security and Technology, ISMG

Kirk was executive editor for security and technology for Information Security Media Group. Reporting from Sydney, Australia, he created "The Ransomware Files" podcast, which tells the harrowing stories of IT pros who have fought back against ransomware.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.com, you agree to our use of cookies.