Cryptocurrencies & Security

The blockchain technology is reputed for its security. As its name indicates, a blockchain is a chain of blocks that contain records of transactions. Each block is connected to all the blocks before and after it. It is then difficult to tamper with a record since an attacker would need to modify the block containing that record as well as those connected to it to prevent being detected. Cryptographic algorithms are used to secure records on a blockchain. Nodes have their own private keys that are uniquely assigned to the transactions they make and act as a personal digital signature. If a record is tampered with, this signature will become invalid and the network will immediately know that someone tried to alter the record.

Blockchains are, by definition, decentralized and distributed across peer-to-peer networks that grow by the minute and are continually updated and synchronized. By being decentralized, blockchains do not have a single point of failure (SPOF) like ordinary routers and cannot be tampered with from a single machine.

Yet, we hear often of cryptocurrencies being stolen or hacked. So, are those security flaws a consequence of the blockchain’s architecture or is it due to other factors? Proposed here is a quick analysis of various famous hacks that occurred to understand the causes underlying those security breaches.

One of the most famous and oldest hacks was, without a doubt, the 2016 DAO exploit.

The hacker realized that the ‘splitDAO’ function of the main code DAO.sol was vulnerable to the, now well-known, recursive send pattern: the ‘splitDAO’ function updates user balances and calculates the total at the end, so if a hacker can get any of the function calls before this happens to call ‘splitDAO’ again, they access the infinite recursion that can be used to move as many funds as they want.

function splitDAO(

uint _proposalID,

address _newCurator

) noEther onlyTokenholders returns (bool _success) {

…

// Move ether and assign new Tokens. This is done first.

uint fundsToBeMoved =

(balances[msg.sender] * p.splitData[0].splitBalance) /

p.splitData[0].totalSupply;

if (p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender) == false) // This is the line the hacker wants to run more than once

throw;

…

// Burn DAO Tokens

Transfer(msg.sender, 0, balances[msg.sender]);

withdrawRewardFor(msg.sender); // Gets the rewards

// Notice the preceding line is critically before the next few

totalSupply -= balances[msg.sender]; // This is done last

balances[msg.sender] = 0; // And this as well

paidOut[msg.sender] = 0;

return true;

}

The idea behind the hack was to propose a split and execute it. When the DAO withdrew the reward, the function to execute a split was called before the withdrawal could finish. By doing so, the function started running without updating the balance, and the line marked above as “the attacker wants to run more than once” was running more than once. Once this happens, the source code transfers tokens from the parent DAO to the child DAO. In other words, the hacker is using this function to transfer more tokens than they normally should be able to into their child DAO.

Another famous hack was the Parity wallet hack.

As calling functions on the smart contract to interact with it costs Ether (ETH), this motivates a developer to optimize their code, both to minimize transactions and minimize computation costs. Using libraries is one way to achieve cost reductions. Making the contract call out to a shared library will directly save money, as those libraries are already deployed.

That is what the Parity multi-sig wallet did. It held a reference to a shared external library which contained wallet initialization logic. This shared library is referenced by the public key of the library contract. All the needed right permission checks were contained in the wallet, and they were sure to carry out authorization on sensitive actions related to the wallet’s state. Unfortunately, a mistake was made.

Solidity allows for “fallback” methods. Those methods are called when there is no method that matches a given method name. In Parity’s case, an unknown method that sends ETH to the contract will fail to deposit the sent ETH. However, the Parity team took it further, and they made a mistake. Below is the code that was attacked:

function() payable {

if (msg.value > 0)

Deposit(msg.sender, msg.value);

else if (msg.data.length > 0)

_walletLibrary.delegatecall(msg.data);

}

If there is no method that matches a given method name, and if no ETH is being sent in the transaction, and if there is some data in the message payload, then it will call the exact same method if it is defined in _walletLibrary.

Using this, the hacker called the method below named initWallet(), which was not defined on the multi-sig contract but was defined in the shared wallet library referenced:

function initWallet(address[] _owners, uint _required, uint _daylimit) {

initDaylimit(_daylimit);

initMultiowned(_owners, _required);

}

This function calls the initMultiowned method below:

function initMultiowned(address[] _owners, uint _required) {

m_numOwners = _owners.length + 1;

m_owners[1] = uint(msg.sender);

m_ownerIndex[uint(msg.sender)] = 1;

for (uint i = 0; i < _owners.length; ++i)

{

m_owners[2 + i] = uint(_owners[i]);

m_ownerIndex[uint(_owners[i])] = 2 + i;

}

m_required = _required;

}

The hacker reinitialized the contract by delegating through the library method, overwriting the owners on the original contract. Any array of owners supplied by the attacker as arguments will become the new owners.

The control of the entire wallet has now passed from the Parity team to the hacker. They now only have to extract the remainder of the balance into their own wallets.

The most recent and biggest hack to date is the Coincheck hack that led to the loss of US$500 million.

According to Coincheck, the attackers were able to access the hot wallet private key and steal the NEM coins contained in the wallet. It was revealed that the NEM coins were stored on a simple hot wallet rather than a more secure multi-sig wallet. Coincheck used multi-sig wallets to store other cryptocurrencies on the exchange; however, for some reason, the NEM coins were not. Company representatives declared that “security standards were not low”. Yet, the fact that the NEM were not protected in multi-sig wallets suggests the contrary.

To secure ourselves from such attacks, Equadex has learned from these hacks and uses a completely different approach in its smart contract and how the coins are stored. Furthermore, the code has been audited by a third-party to ensure such breaches do not occur.