Smart Contract Security – Part 2 of the Smart Contract Series
In June 2016, attackers drained TheDAO smart contract of 3.6 million Ether (valued at $70M at the time) due to a vulnerability in the smart contract’s code, which made it possible to withdraw money from it without any change being made to the withdrawer’s balance.
In August 2018, the DApp game Last Winner was drained of almost 13k Ether by a group of malicious actors.
These are just two of the biggest attacks on smart contracts. Since smart contracts deal directly with currency, they are often targeted by malicious entities looking to make a quick buck.
Let us take a deeper look at TheDAO Hack.
TheDAO Hack – Deep Dive
Imagine having $500 in your account, and you withdraw $100 from it, but the bank does not update your balance. You withdraw another $100, but your account balance still shows up as $500. You could essentially end up withdrawing all the money held by the bank. What happened during the DAO attack was something similar. The attacker was able to withdraw funds from the DAO contract recursively, which is also known as a reentrancy attack.
A DAO, or a Decentralized Autonomous Organization, is an organization which is not governed by a single entity, but rather, each decision proceeds only with the approval of the entire group. The rules which govern a DAO are embossed within its smart contract code, which is completely transparent and open to verification by everyone.
Let’s get into how the attack was carried out. The DAO.sol contract had a vulnerable piece of code, a function called splitDAO:
function splitDAO( //The vulnerable function
uint _proposalID,
address _newCurator
) noEther onlyTokenholders returns (bool _success) {
...
//Moving ether and assigning new Tokens
uint fundsToBeMoved =
(balances[msg.sender] * p.splitData[0].splitBalance) /
p.splitData[0].totalSupply;
if (p.splitData[0].newDAO.createTokenProxy.value(fundsToBeMoved)(msg.sender) == false) // XXXXX This is the line the attacker wants to run more than once
throw;
...
// Burn DAO Tokens
Transfer(msg.sender, 0, balances[msg.sender]);
withdrawRewardFor(msg.sender); // Caller gets their rewards
totalSupply -= balances[msg.sender]; // Total supply being updated in the end
balances[msg.sender] = 0; // Line X - Balance being updated in the end
paidOut[msg.sender] = 0;
return true;
}In this function, if the caller proposes and executes a DAO split, the reentrancy attack is triggered since the withdrawRewardFor function sends tokens to the caller, who can use a contract with a malicious fallback function to repeatedly execute the splitDAO function before it gets a chance to execute Line X as marked in the code snippet above. This essentially allows an attacker to withdraw funds from the contract indefinitely.
The DAO hack was the biggest smart contract attack of all time, but if something good came out of this, it was the fact that people were starting to realize the importance of security for smart contracts.
This attack is also famous for introducing the hard fork into the Ethereum blockchain, which resulted in the emergence of the Ethereum classic. Since blockchains are immutable, it is not possible to change a smart contract code once it has been deployed. Hence, in order to fix the vulnerable code, Vitalik Butarin (founder of the Ethereum blockchain), suggested a hard fork – the fixed code would be deployed in a new version of the blockchain, which would not contain any history of the vulnerable code at all. It was expected that this would lead to the original chain being abandoned eventually, but instead, it became to be known as Ethereum Classic by members of the community who were not entirely satisfied with the decision to create a fork.
Smart contracts and Decentralized Apps have been around for a few years now, but they are relatively new and evolving fast. These technologies are rapidly developing, always in flux, and changing constantly. This means that they are a prime target for hackers looking to profit off of unsecured code in smart contracts. That is why smart contract developers need to make smart contract security a priority NOW.
This brings us to the DASP Top 10.
Decentralized Application Security Project (or DASP) Top 10:
The DASP Top 10 is a list of the top 10 most common security vulnerabilities found in smart contracts.
- Reentrancy Attacks
This is the type of attack targeted against the DAO in 2016. This type of attack occurs when the external contracts are able to make newer calls to the vulnerable contract before the initial execution can finish, often resulting in the newer calls getting executed without the state variables being changed.
- Access Control
Access control vulnerabilities are very critical, and are present in all kinds of applications, not just in smart contracts. If function calls aren’t restricted to the addresses with the appropriate access levels, attackers may try to perform critical state changes which should only be accessible to contract owners.
- Arithmetic Issues
Integer overflows and underflows are the arithmetic issues that arise in smart contracts. Although this issue is decreasing in severity due to updates being made to smart contract languages themselves, using unsigned integers can give rise to this vulnerability.
- Unchecked Low-Level Calls
There are certain low level function calls, like call(), send() and delegateCall(). If an error occurs during the execution of these functions, they do not reverse the current execution, and instead, only return a boolean false value.
- Denial of Service
If an attacker can exploit a Denial of Service attack on the blockchain, they can essentially break/stop the smart contract. There are lots of ways for attackers to exploit Denial of Service attacks on smart contracts, including exploiting access control issues, malicious behavior on being the recipient of a function call from within the smart contract, etc.
- Bad Randomness
It is very difficult to get randomness working properly within a smart contract. It is advisable for developers to avoid relying on randomness for critical function code since it can be replicated by an attacker and exploited.
- Front Running
Front-running attacks are possible due to the fact that all transactions on the blockchain are public. This type of attack occurs when a malicious entity copies the solution to a problem within a smart contract from someone else’s pending transaction on the blockchain and submits that along with a higher gas fee so that the miners pick up the attacker's transaction first.
- Time Manipulation
Sometimes, smart contract logic requires using the current timestamp for some operations. These timestamps are provided by the miners who include the transactions in the blocks they mine. However, since miners have some control over reporting the exact time at which the block was mined, it is not advisable to rely upon timestamps within a smart contract.
- Short Addresses
These issues can occur as a result of the EVM (Ethereum Virtual Machine) accepting poorly padded arguments within function calls. If a malicious actor passes in a short address to a _transfer(address, amount) function, the EVM will try to pad the missing byte to the amount argument, thereby increasing the amount of tokens transferred.
- Unknown Unknowns
Since smart contract technology is still in its infancy, it is very likely that new threats and attack vectors will continue to be discovered as smart contract development evolves and grows rapidly. There are a lot of unknown factors here, and that continues to be one of the most severe issues plaguing smart contract development today.
In part 3 of this series, we will demonstrate how to use tools to perform smart contract security audits.
Worried about attackers targeting your smart contracts? Contact us today to get your smart contracts audited for any security issues!
Anshul
Anshul is a cybersecurity analyst at DeTaSECURE. He has helped multiple organizations secure their digital assets as a security professional. He holds certifications like CEH and AZ-900. You can reach out to him by Clicking Here.