Last updated at Tue, 14 May 2019 19:34:02 GMT
Over the weekend, we had a discussion at tCell about cryptocurrency, because there was a rash of stories about cryptocurrency mining being done through malicious JavaScript. (Scott Helme of securityheaders.io noted that the Information Commissioner’s Office, the UK’s data privacy regulator, was among the many web sites affected.) According to one story from last year, cryptocurrency mining through JavaScript is now common enough that some web and application administrators are receiving unsolicited email offering to pay for their site by kicking back a portion of the cryptocurrency mined by visitors!
The short version of this threat is that an attacker inserts JavaScript into the user content, and that script mines cryptocurrency as long as the web page is open. The end user can be none the wiser, unless they look at CPU utilization or notice that the computer has slowed down while the page is open. It helps if you have an audience that is interested in your content. Even YouTube has been affected, with ads served through the DoubleClick network being used to push background miners to viewers. (This is not the first time we’ve written about DoubleClick on the tCell blog.) One of the best-known Javascript mining toolkits is called Coinhive, though there are others.
One of the biggest barriers to mining cryptocurrency profitability is that currencies are designed to be hard to generate, and new currency is created only after something “proof of work.” As more computers are engaged in mining, the harder it gets. There’s a reason why mining operations have gravitated towards low-energy cost areas. There are many introductory calculators on the profitability of mining, mostly focused on Bitcoin because it has been around the longest and has had the most specialized hardware developed to mine it. One of major costs of cryptocurrency mining is electricity. Here in San Francisco at tCell headquarters, electricity sells for about 20 cents per kilowatt hour (c/kWh). In the Pacific Northwest, with its abundant hydropower dams, electricity is significantly cheaper. Seattle residents will pay less than half of that, at 8 c/kWh. Google says our Swedish tCell colleagues pay 19 euro cents, which is about 24 c/kWh at current exchange rates. To mine profitably, you need cheap electricity, and the electrical power in Mongolia — at just 4 c/kWh — is one of the major attractions to locating large-scale cryptocurrency mining operations there.
Many calculators or articles about mining conclude with a statement that mining doesn’t make financial sense without a source of cheap (or better yet, free) electricity. Coinhive always makes sense for attackers because they steal computing resources without paying, and therefore, it does not matter how inefficient it is. (Mining has long moved away from general-purpose CPUs and to GPUs and specialized chipsets.)
So, how can you protect yourself? As an end user, your options are limited. Many sites that use Coinhive appear to have been hacked, so you’ll need to pay attention to your system performance to notice when certain applications or web sites appear to take significant resources.
Due to the difficulty in detecting stealthy resource theft, many of the protection guides are focused on what web and application administrators can do to protect their users.
Here’s a quick run-down of some of the best advice we’ve seen at tCell:
- Defend your web servers from attackers so that attackers cannot insert cryptocurrency mining scripts like Coinhive’s scripts into your content. Many hosting companies, cloud computing platforms, and content distribution networks offer basic protections, and there is a huge list of security tools available for securing web sites and detecting defacement or other content changes. Well-known security problems such as the Apache Struts security hole made famous by Equifax can be used to install Coinhive on unprotected web sites.
- Use the Sub-resource Integrity (SRI) function to ensure that content loaded from other sites is not altered. Essentially, when content is pulled in from a parent page, a cryptographic hash of the code is computed and the code only executes if the computed hash matches the value in the parent page. This works well for static or infrequently-changing content, but the need to change the hash value in the SRI attribute when the underlying content changes is a challenge for dynamic content. SRI can be used to protect seldom-changing resources such as calls to analytics pages, but it would not work very well for highly dynamic content such as discussion forums or the Disqus comment system. As an additional administrative challenge, SRI sometimes also requires Cross-Origin Resource Sharing (CORS) to be configured as well.
- Use Content Security Policies (CSP) to restrict applications from loading content only from authorized domains. As you create your web application, you explicitly authorize it to obtain content from known locations. Any content from unauthorized domains will be blocked. Unless you, as the server administrator, allow the Coinhive JavaScript to be fetched from or report to another site, it will be blocked.
Here at tCell, we’ve integrated CSP into our product. When you deploy tCell to protect against attackers, you also extend protections throughout the complete application into the user’s web browser. We’ll also protect against cross-site scripting attacks that can be used to sneak the Coinhive script into the web browsers of your users. Want to learn more? Give us a call!