On the dangers of In Browser Cryptocurrency Mining, and how I got 1000s of computers to mine for me.
In the 90’s, a proposition was put forward to limit Email spam. Emails would be validated by senders using a Proof of Work (POW) algorithm that required some amount of CPU time and computation.
The system, called HashCash, was rejected because of fears that spammers could simply use other computers’ processing power to do this work. Twenty years on, and we’re beginning to see why this decision was made.
Now, an idea has arisen based on a similar POW concept. When users browse to a website, their computers can do some work in order to forego advertisements.
In Browser Crypto Mining
This concept is called In Browser Crypto Mining (IBCM). Yup, that’s a thing…
Between the news headlines and incessant social media chat, it seems like everywhere you go some libertarian appears asking to discuss Bitcoin or the Blockchain, like a religious wing-nut in Times Square.
It’s usually fine to zone out when this happens, but you shouldn’t now. That’s because this story of magic internet money is scary and it involves you.
When you load a website, the code running in your browser can turn your computer into a cryptocurrency miner and send the rewards off to the owner of the website. Specifically, the currency mined is Monero (XMR, $345.12). The idea of IBCM goes: the User, in exchange for visiting the Website, pays a small fee to the Website Owner. This fee is in the form of Monero, which is mined on the User’s computer. It is essentially a swap of electricity for the ability to forego advertisements.
Mining = Electricity = Money.
The hope is that website owners will use this software transparently to charge you so they don’t have to display adverts. However, just like HashCash, this notion could be dangerous.
The reason lies in the fact that it is extremely hard for the Website Owner or You to detect when this software is running. Oh, and it is not just Website Owners who can choose to run IBCM. Anyone can….
Just don’t refrigerate your computer
What if I told you that if you’ve visited any of these websites in 2018, then your computer has literally mined Monero for someone else: youtube.com, facebook.com, all Word Press pages, or any of these 4200 websites.
This is not happening in obscure corners of the internet; even multiple Government Websites (including the UK’s NHS site) have all fallen victim to what I would definitely call ‘malicious software’. And that makes you a victim.
Right now, IBCM is mostly being done surreptitiously WITHOUT the knowledge of website owners or YOU.
It turns out that naughty people have been injecting this software onto websites. This essentially puts your entire computer and its processing power into their hands when you visit that site. Your CPU becomes part of their Monero mining pool, performing up to on the order of 200,000 Millions of Instructions per Second (MIPS). Not only are they draining your electricity but also impeding other programs’ performance and your processor’s resources.
It’s crazy to think that this appropriation can happen so easily. Illustrating how and why is the main purpose of this article.
Client-side Injection Attacks
There are three main methods that hackers use to get their mining code into your browser.
Cross-site scripting (XSS), Improper Input Handling
XSS is the third most common webpage vulnerability. Unsanitized user inputs give hackers an entry to websites. The call to eval above would execute any code in the victimʼs browser context, including malicious mining code.
A final method of attack is through browser extensions. Extensions can render any JS script through content scripts in any tab in your browser, serving as another entryway for malicious code.
These plug-ins are dangerous because they pervade the browser, allowing malicious code to be executed in any website no matter how secure.
This is how all Chrome extensions work. So it would behoove Google to protect Chrome users against malicious extensions, like ones that mine cryptocurrencies.
Chrome Extension Malware Detection
Google have an automated security screening process of questionable proficiency. Some have called it a “joke” and others, “one of the largest single security threats to the web right now.” So I did a bit of digging into Chrome’s malware detection model to find out why.
The feature set for classification consists of a collection of over 20 million signals. That’s for a training set of 99,818 extensions. 😬
The automated detection uses an implementation of online gradient descent logistic regression with Lasso L1 regularization. That is to reduce the feature set of size 20 million down to something more reasonable, though in a computationally inefficient way. A possible improvement here would be to follow L1 regularization by an L2 regularized model-building step, to minimize the influence of outliers.
This model also runs the risk of overlooking cloaked malware; malicious developers may delay execution until after dynamic analysis takes place, obfuscate code, or fingerprint IP addresses used in the model.
Furthermore, the detection scheme doesn’t achieve a wide code coverage since extensions are event-driven and have many branches. There is no sub-model trained to explicitly search for activation pathways.
Finally, the fact that this model is public means that malevolent developers can train their extension to be classified incorrectly.
Blocking the Bulk of Malicious Extensions
To compensate for the massive amount of features, they multiply the gradient descent learning rate with a correction factor that is proportional to an approximate confidence level, assigned by known malware items.
They look for specific threats; outgoing POSTs that may indicate unauthorized account manipulation, DOM operations that replace adverts, Torpig banking trojans and so on.
All in all, the prediction model finds most malicious extensions (80%+). It does a good job of eradicating clear signs of abuse, but seems not yet to find extensions that incorporate IBCM.
I hope this isn’t Illegal
So I decided to test my hypothesis. Not only did I want to create a malicious extension to see if Chrome took it down, but also to check how many people online were protecting themselves against IBCM.
I created a simple Chrome extension to change the browser’s colour temperature just like Flux. But also to mine cryptocurrencies. Then, I embedded mining code on a website I built last month. I also allowed my code to throttle the victim’s processing power (see code below), on any number of the victim’s cores.
Only 7% of accesses to my malicious code were blocked; the rest let me slide right on in.
In just a few weeks, I had turned over 1200 CPUs into my very own money making machines.
Here are a few ways we could block IBCM, and a few reasons why protecting ourselves is rather difficult.
Blacklisting and Validating Content
First off, you could have a content script run against the rendered HTML and blacklist known malicious domains and IP addresses. Extensions like No Coin hardcode known malevolent domains and block them.
These extensions could also grep for known 3rd party miners CDNs like coinhive.min.js and digimine.min.js.
Most browsers validate embedded content using Subresource Integrity (SRI). Comparing the ‘integrity’ cryptographic hash (such as SHA-3 checksum) provided by the website owner to the computer hash of the resource fetched would expose compromised assets. In the case that these external assets are hijacked, the browser would be able to block them.
Monitor your CPU
A second method would be to monitor CPU load, to see if your cores are in overdrive. The browser could have an energy threshold above which a potential mining warning would be raised. Or if we wanted to be really smart, we could implement a model which would only flag abnormal CPU usage.
However, since JS is based on a single event loop, this type of monitoring would be performance costly; it would be like killing a fly with a submachine gun. Not to mention that this would itself be a hack, since the browser shouldn’t have access to this kind of information.
Additionally, legitimate CPU intensive processes like video games and Netflix could be mistaken for mining. Miners could try and fly under the radar by throttling back the mining rate, or replicating the performance of video playback.
Check your scratchpad
The final method of detection is definitely the most clever. To understand it, we have to dive into Cryptonote, the protocol behind Cryptonight, Monero’s POW hashing algorithm. This is the coolest thing you’ll learn today.
Cryptonight allocates around 2MB of fast CPU cache (usually L3 cache), one the most expensive piece of hardware on your computer. The allocated memory block (called the scratchpad) is split up and individual components perform rounds of Advanced Encryption Standard (AES) encryption and read/write operations at pseudo-random addresses. Finally, the entire scratchpad is hashed with Keccak to yield the mining output number.
Cryptonight is designed to be inefficiently computable on GPUs, effectively to mitigate the chance of one entity gaining a large proportion of hash power.
This is what makes IBCM viable.
This behaviour arises from a few things; memory in ASICs (like GDDR5, used in Ethereum mining) may have a higher bit rate, but slower random access speed than L3 cache. GPUs also just don’t have enough cache memory to allocate 2MB of work to. In addition, most CPUs are really good at doing rounds of encryption using AES, which comprises most of the Cryptonight algorithm,
Also, heavy calls in a cryptocurrency networks may result in vulnerabilities. Miners must check every new block’s POW. If a node spends too much time on each hash evaluation, it could theoretically be DDoS’ed with arbitrary Merkle Trees requesting validation. This would destabilise the GPU at that node.
Now that we know how Cryptonight works, perhaps we can come up with a way to block it. Simply check internal fast memory (scratchpad) to see if your CPU is doing something which resembles the algorithm.
Taking into account these difficulties, will anything stop IBCM? Analysing Monero mining behaviour in the wake of the exposed Spectre vulnerabilities might give us a hint.
Kernel patches like Kaiser, which affects system calls and interrupts could slow down Cryptonight’s performance by up to 28%. This would impede on miners’ hashrates, making it more costly to mine.
Also, Spectre variant 2 can be used to evict L3 cache memory (where Cryptonight runs) even remotely in-browser. With system level vulnerabilities exposed at the CPU level, perhaps computed hashes could be stolen via side channel timing attacks, even though remote penetrations are harder.
However, we don’t see any sign of reduction in hash rate through January (when vulnerabilities were announced). This highlights Monero’s viability in spite of a potential mining vulnerability and performance hit.
It’s Time for Less Trust and More Self-Defense.
Even in the 90’s, before the days of data driven machine learning, people were aware of the risks of a sort of In Browser Mining.
Hopefully more mainstream workarounds will be constructed in the future to protect us from IBCM. Preventing mining isn’t going to be easy, but companies like Google pride themselves on finding solutions to hard problems.
At the end of the day, defacing a website is fun but mining is profitable. This type of attack will not stop and only you can defend yourself against it right now.
So next time your computer overheats and fans get noisy, you may be able to guess why.
Disclaimer: Please note that this is an opinion piece and for information purposes only. Thanks to Nikhil Bhatia and Jack Dent for their help.