Cryptocurrencies have been around for more than a decade now. During this period, we have observed more than a hundred major hacks of cryptoexchanges and other cryptocurrency-related services.

Very often, the details of the hack remain unclear. It&#;s easy to learn who was hacked, when it happened, and how much was stolen, but the &#;how&#; remains elusive. Journalists are more interested in the sums involved, and victimized organizations are in no hurry to disclose the details of their shame.

Let&#;s fill in the gaps and talk a bit about how those hacks work — not to preach but in the hopes of preventing a recurrence.

Phishing and malware: The standard cryptoexchange hack

Cryptoexchanges store users&#; cryptocurrencies and ordinary money in conventional bank accounts. For cybercriminals, getting involved with ordinary money is risky; to get away with stolen loot, they would need to cash it quickly before the bank had a chance to freeze the accounts. That&#;s why hackers typically opt for cryptocurrency.

From the outside, the first and perhaps only facts known about a typical cryptoexchange hack are (1) that it happened, and (2) that clients&#; money is gone. But what really happened? Most likely, the following: First the attackers obtained a list of employees, studied their interests (including on social networks), and sent targeted phishing e-mails with malicious payloads to those they deemed the most potentially gullible. That way, the cybercriminals got inside the exchange network.

Next, they learned their way around the firm: how often the accountant communicated with the director, what they sent each other, the architecture of the internal network, where the cryptowallets were stored, and how they were protected. This stage can take a lot of time, but eventually it leads the cybercriminals to the machine of an employee with access to critical systems.

If the exchange&#;s automatic system is set up to send cryptocurrency, then having operator rights means the attackers can send cryptocurrency to themselves. A recent attack on the Binance exchange is believed to have unfolded according to such a scenario.

Targeted attacks: How to stay protected

If your business is a cryptoexchange, then your task is to make sure that the cost of an attack exceeds the potential gain multiplied by the probability of success. Hence the need to:

• Train staff in cyberliteracy (for example, not opening a résumé in DOC format);
• Use a security solution to protect against targeted attacks — preferably one that not only guards against threats on each specific node, but also looks for anomalies across the organization;
• Order a pentest (during which security experts try to penetrate and navigate around your system, and then tell you where the weak spots are).

Double-spending: Robbing a Bitcoin ATM with a phone

Another path to stealing bitcoins emerged in the form of ATMs. People typically use ATMs simply to withdraw money from (or deposit it into) their existing bank accounts, but a Bitcoin ATM adds more: the ability to buy and sell cryptocurrency.

To run a bitcoin scam through an ATM, people could use the machines to sell bitcoins, receiving a cash payout, and then cancel the transactions. Sounds too obvious to work, but for one example, within a short time of 45 cryptocurrency-enabled ATMs appearing in Canada, thieves made off with $, from them.

How could that happen? As you know, information in the blockchain is stored in blocks, hence the name. A transaction such as &#;Sending 1 BTC to John&#; is not immediately written to the block; it first gets queued, and a new block is created roughly once every 10 minutes. Any unconfirmed transaction gets removed from the queue by the block creator. It should be noted that there is not enough space in the block for all transactions, so priority is given to those with higher fees (which the block creator retains).

It&#;s hard to believe, but the logic developers behind the ATMs did not instruct them to wait for transactions to be written to the blockchain before dispensing cash. User convenience trumped security.

One more tiny detail: Initially, Bitcoin did not allow the cancellation of queued transactions, which often led to transactions with small fees attached hanging in the system for several days before being removed. To solve that problem, Bitcoin added a replace-by-fee mechanism, allowing a transaction waiting in line to be replaced with another — typically to hike the commission and get the transfer pushed through. But this mechanism also makes it possible to change the recipient, sending the bitcoins back to the sender.

To call it a vulnerability would be putting it mildly. It was sheer recklessness. And here is what it led to:

Double-spending hack: How to stay protected

After the money was stolen, the company behind the ATMs changed out its machines to incorporate a wait time. Now, users need to return to the ATM to receive their cash after the bitcoins have been delivered. It&#;s much less user-friendly, but that&#;s the only way to do it properly considering the blockchain&#;s mechanics.

In hindsight it&#;s clear that to prevent such a stupid loss of money, the developers should have ordered an application security review. That involves having outside experts examine the architecture of your service, view the code, and look for vulnerabilities.

The 51% attack: Mastering the blockchain

You&#;ve probably heard the immutability axiom: &#;Data in the blockchain cannot be altered.&#; But that&#;s not the whole truth in some cases. To understand in more detail how the blockchain and mining work, check out &#;What is blockchain technology and how it works&#; and &#;Explainer: Bitcoin mining.&#;

Two principles guarantee that the blockchain is the same for all users. First, all of the participants need to agree who the creator of the next block will be. The probability of being the lucky one depends on the resources invested — the more mining power, the better the chances.

Second is the &#;longest chain rule,&#; which states that in case of conflict the valid version of the blockchain is the longest one. If someone forges their own version of the blockchain and tries to broadcast it, everyone else will reject it because fewer resources were expended on it and thus it is shorter.

But the situation changes if the forger uses more than 50% of all mining power. In the time it takes all other miners to create, say, nine blocks, a malicious user might create At this moment the forged version of the blockchain becomes the longest one, therefore everybody accepts it, and the financial history is effectively altered. A user who spent bitcoins in the old version of the public blockchain would find those bitcoins back in their account in the forged blockchain.

That is precisely what happened to the conwaytransport.com.au cryptoexchange in early An attacker sent their cryptocurrency to the exchange (and wrote this fact to the public blockchain), and meanwhile set about creating his own blockchain. When the exchange received the transfer and credited the amount to the attacker&#;s balance, the latter broadcast its private blockchain (which did not contain the above transaction, allowing the cryptocurrency to be repocketed) and requested a withdrawal of its balance from the exchange. As a result, the exchange lost money.

Now let&#;s see why this is not an everyday occurrence, and how much computing power the attacker had to expend.

We&#;ll use Bitcoin as an example. Miners create six blocks per hour. For each block, a reward of BTC is issued. (On October 6, , 75 BTC equaled $,) That&#;s roughly how much it costs to rent all Bitcoin-mining power for an hour. The Crypto51 site shows such calculations:

Estimated cost of one hour of a 51% attack on major cryptocurrencies

The last column specifies how much capacity is available for rent right now. As you can see, to take possession of the Ethereum Classic blockchain, as the abovementioned attacker did, would cost about $10, per hour. They needed four hours to take in $,

Note that this is not the first attack of this type. Various other cryptocurrencies have endured successful 51% attacks.

51% attacks: How to stay protected

In general, the ability to rewrite a blockchain and cash in on a 51% attack is an innate feature of the technology. To make an attack as expensive as possible, cryptoexchanges try to wait as long as possible before updating the user&#;s balance after a transaction. That&#;s because the more blocks created since the transaction entered the blockchain, the less likely it is that the blockchain will get reorganized and rolled back. But the delay causes the major inconvenience of transfers taking hours to go through.

In any case, we will surely see this kind of attack again.

Secret key theft: Passphrase spellcheck

To spend cryptocurrency, you need the secret key. The key is what is saved in cryptowallets; the user&#;s balance is stored in the blockchain.

If you switch cryptowallets, you must copy the key from the old wallet to the new one. For convenience, the key consists of a seed phrase made up of 12 simple words — for example, witch collapse practice feed shame open despair creek road again ice least.

Once, the developers of a cryptowallet accidentally sent this phrase online for a spellcheck, a mistake that a cryptoinvestor discovered after suffering a $70, theft. We doubt this was the reason for the theft, but in any case the story is instructive.

It happened because nowadays, applications are commonly not written from scratch, but rather assembled from components, including components from third-party developers. That&#;s how the developers of the Coinomi cryptowallet proceeded. To display the passphrase input form, they used the jxBrowser component. Unbeknownst to the developers, this component by default spellchecks all text entered in the form. And so as not to be laden with dictionaries for all of the world&#;s known languages, it performs a cloud-based check using conwaytransport.com.au

For ordinary input forms, this can be handy, but for input fields that accept passwords and super-secret phrases, it&#;s terribly risky.

In their defense, the developers stated that the seed phrase went to Google only and was transmitted in encrypted form. And Google returned an error. Nevertheless, the victim is sure that this vulnerability was the cause of the theft.

Secret key theft: How to stay protected

On the one hand, commonplace carelessness caused the problem. The component&#;s spellcheck feature was documented, and the instructions described how to disable it. Conventional testing would probably not have identified the issue, but an application security review definitely would have.

On the other hand, the problem runs deeper than that. The use of third-party libraries opens up potential issues, either now or in the future (if their updates make them vulnerable), as well as the risk of a supply-chain attack. In a supply-chain attack, a cybercriminal has no need to hack the original developer of the tool; they merely need to breach one of its contractors. Often, contractors are not as well protected, and they may not even be aware of which important projects their code will be used in.

Sometimes you scratch your head at the recklessness of those responsible, and other times you sympathize with how helpless they are.