Cyrptomag

After a few evolutionary steps via Application Specific Integrated Circuits (ASICs) mining algorithms seem to have returned to their roots: the ‘humble’ personal computer. The suitability of algorithms such as CryptoNight (which underlies the Monero currency) ultimately led to the porting of the source code to JavaScript and a departure from the more traditional approach of having standalone executables for mining, instead executing code from within browser processes. This blog looks at the development and modern realities of in-browser mining.

We covered the basic concepts of blockchain, cryptocurrencies, and coin mining in our previous blog.

As we discussed, after a few evolutionary steps via Application Specific Integrated Circuits (ASICs) mining algorithms returned to their roots: the ‘humble’ personal computer. The suitability of algorithms such as CryptoNight (which underlies the Monero currency) ultimately led to the porting of the source code to JavaScript and a departure from the more traditional approach of having standalone executables for mining, instead executing code from within browser processes.

The beginning of in-browser mining
This new approach meant that any browser supporting JavaScript could be used for coin mining, and services soon arose to use the process for the monetisation of websites. This naturally appealed to cybercriminals as there was now no need for the laborious process of deploying and keeping binaries persistent – all that was required was a simple code injection on a web page.

The downside of this solution is that, while JavaScript is platform independent, it runs in a browser sandbox, far away from the bare metal and therefore from optimal performance. Another considerable aspect is persistence: while the earlier PC- and IoT-based implementations would run practically forever (or at least until someone found and killed the corresponding process) the browser-based approach can only work for as long as the page containing the miner is kept open.

On the other hand, for malicious actors, the web-based approach also provides extra flexibility: there is no need to store everything on the same page. Functionality and components can be split across multiple domains, and previously rented or hacked servers can be (re)used for a new purpose.

For many, ‘virtual’ currencies such as Bitcoin remain a mystery primarily associated with online criminals, despite no longer being far removed from the monetary system and transactions we’re used to. This article is intended to serve as a primer, rather than one of our more usual technical analyses: cryptocurrencies continue to play a key role in many areas of cyber-crime being used for everything from online marketplace transactions to ransomware demands. However, with a number of legitimate organisations ranging from the Bank of England to EY also taking an interest cryptocurrencies and the technologies behind them, it’s worth being informed.

Virtual currencies
The 2000s saw an increase in the number and utility of entirely virtual currencies (as opposed to digital currencies backed by some form of legal tender).

A number of dry definitions of ‘virtual currency’ exist, with the European Central Bank defining it as:

“a type of unregulated, digital money, which is issued and usually controlled by its developers, and used and accepted among the members of a specific virtual community”[3]

By this broad definition, a number of things qualify as virtual currencies: while some online games such as World of Warcraft forbid the exchange of the in-game currency for any other form of money, a black market engaging in just this exists. Equally, a number of online marketplaces – especially within the gaming community – require the one-way exchange of legal tender for virtual currencies, e.g. Microsoft Points.

Of course, a common feature of all of the currencies discussed so far is that they’re centralised: the Federal Reserve is the centralised authority and repository for US dollars, GS&R – the company behind E-Gold – held a centralised ledger tracking transactions, and Microsoft naturally keep track of Microsoft Points.

While not legal tender, the value of these currencies is agreed and accepted by all of the parties involved – much as people generally accept the declared value of paper money or an electronic bank transfer.

The arrival of Bitcoin in 2009 – the first and, arguably, most famous decentralised virtual currency – had a significant impact.

You are responsible for people.’

It was one of a dozen or so subject lines that shouldered their way into people’s inboxes across the world last week, bringing with it a sobering threat of violence via bomb threat.

For the past year Forcepoint Security Labs have been monitoring a persistent strain of hoax emails attempting to blackmail or otherwise extort their recipients. This type of email has been widely reported, and the sheer scale indicates that it can’t be taken as anything but an empty threat.

Violence as a motivator
However, one of last week’s campaigns brought with it a significant change: instead of sending wild (and occasionally lurid) threats of embarrassment, the perpetrators were threatening victims with bomb and acid attacks.

These hoaxes attempt to gain some credibility by mentioning explosive chemical names (e.g. hexogen, lead azide, trinitrotoluene, tetryl). These messages further included a higher than previously recorded demand of $20,000 – presumably as the perpetrators now expected to be targeting organisations with more money at their disposal than the individuals targeted by previous campaigns.

However, the complete lack of specific information about the victim within the email is the first suggestion that all is not as it seems, and inspection of the campaign overall reveals a template email sent to many different companies across the world.

Non-specific phrases such as ‘the building where your company is located’ and ‘you must send money by the end of the working day’ highlight the catch-all nature of the emails and would imply a bizarre lack of knowledge on the part of the perpetrator in the case of a real bomb threat.

Multiple Final Alerts
The definition for a final alert does not include a few fields. Because alerts are identified by their hashes, changing the ommitted fields allows an Alert to be classified as a final alert but still be an alert that is added to the infinitely sized map.

Since setCancel is not required to be empty for an alert to be a final alert, the setCancel field can contain different integers to produce alerts that have different hashes and are thus different alerts. Combined with the infinitely sized map and the infinitely sized setCancel issues, many final alerts can be created which are large, fill the map, and cause a node to run out of memory.
The strComment field, while having a maximum length of 65536 bytes, is not required to be a particular string in order for an alert to be a final alert. Thus multiple final alerts can be crafted which have different hashes by using different values for strComment
ThestrReserved field, while having a maximum length of 256 bytes, is not required to be a particular string in order for an alert to be a final alert. Thus multiple final alerts can be crafted which have different hashes by using different values for strReserved.
The nVersion field is also not required to be a particular value. Thus this can be used to construct final alerts with different hashes by having different values for nVersion.
nRelayUntil field is also not required to be a particular value. Thus this can be used to construct final alerts with different hashes by having different values for nRelayUntil.
Final Alert Cancellation (CVE-2016-10725)
Although the final alert is supposed to be uncancellable, it unfortunately is cancellable due to the order of actions when processing an alert. Alerts are first processed by checking whether they cancel any existing alert. Then they are checked whether any of the remaining alerts cancels it. Because of this order, it is possible to create an alert which cancels a final alert before the node checks whether that alert is canceled by the final alert. Thus an attacker can cancel a final alert with another alert allowing a node to be vulnerable to all of the aforementioned attacks.

Protecting Against DoS Attacks from the Alert System
Fixing these issues is relatively easy. The first and most obvious solution is to simply remove the Alert system entirely. As nodes upgrade to versions without the Alert system, fewer nodes will be vulnerable to attack should the Alert keys become public. This is the option that Bitcoin has taken. However, because Bitcoin has retired the Alert system entirely, the Alert key will also be published to reduce the risk that the Alert Key is mistakenly depended upon in the future.

Should altcoins wish to continue using the Alert system but with a different Alert Key, a few very simple fixes will safeguard nodes from the aforementioned issues. Limiting the number of alerts, the size of setCancel and setSubVer, and only allowing one final alert altogether fix the above issues. This patch, on top of Bitcoin Core 0.11 (a vulnerable version), fixes the aforementioned issues. Altcoins that still use the Alert system are recommended to port this patch to their software. Outdated node software is still vulnerable.