Smart contracts are the basis of NFT projects, dApps, and transactions on the blockchain among many other things. The point is that they’re of utmost importance so you don’t want anything wrong with them. However, vulnerabilities and errors in smart contracts are more common than you think. Here are the most common smart contract vulnerabilities to avoid.
1. Reentrancy Attack
A reentrancy attack is when a smart contract temporarily gives up control flow of the transaction by making an external call to another contract, often a malicious one. What does this mean? Let’s say there are two contracts:
- Contract X (vulnerable)
- Contract Y (malicious)
Contract X is coded to check its balance, send funds, and update the balance sheet. In this case:
- Contract Y sends a call to Contract X requesting funds.
- Contract X checks the balance and if sufficient, sends funds to Contract Y.
- Contract Y sends the same call requesting funds over and over again. It does so before Contract X updates its balance sheet.
=> This recurring call-back option ends up draining Contract Y’s funds.
Why Does This Happen?
The reentrancy attack is one of the most common Ethereum smart contract vulnerabilities. It happens frequently because in these contracts calls to functions of other smart contracts occur synchronously.
This means that the calling code waits until the external call is executed before resuming its work. This intermediate state between the call and its execution is when reentrancy attacks often occur.
Contract Y sends a call-back request before Contract X updates its sheets.
Real-life Example
The most known reentrancy real-life attack is the DAO one. An anonymous hacker managed to chain most of the $150 million worth of ETH from DAO’s smart contract.
2. Front-running
The blockchain is a public ledger, meaning everything on it is accessible to the public. This obviously includes smart contracts and transactions. Even though it’s a good characteristic, this exposes smart contracts to other types of attacks.
Another thing about the blockchain, miners select transactions with the highest gas fees. Now, you can see a transaction with its related gas fees that have been published but not yet included in a block.
So, malicious actors can see which transaction has the highest fee, and submit one with a higher fee. Basically, they front-run your smart contract to submit their transaction first.
- Person A sends a transaction with x gas fee.
- Person B sends a transaction with y gas fee, noting that y > x.
- Miners favor Person B’s transaction as it has higher gas fees.
Front-running Example
The DODO DEX hack is an example of front-running. The attacker:
- Created a counterfeit token and called the init() function of the vulnerable smart contract
- Set the reserve of the variable to zero, noting that it has a zero token balance
- Calls init() again but point it to a real token from one of DODO’s pools
- Extracts real tokens from the pools using a flash loan
However, this attacker was attacked by bots through frontrunning the smart contracts. The bots set a very high transaction fee for their transactions. This made their transactions pass 10 minutes before the original attacker.
However, the owners of both of these bots have agreed to return the stolen funds totaling $3.1 million. The remaining $700,000 was stolen by the original attacker, and $200,000 were frozen exchanges.
3. Logic Error
One of the most common smart contract vulnerabilities is logic errors. These include:
- Typographical errors
- Misinterpretations of specifications
- Programming errors
Smart contracts are the base of transactions and dApps. One wrong letter in the code can throw off the entire thing so these logic errors are more serious than one might think.
Real-life Example
One minor typo in the DeFi trading protocol Hegic blocked users’ assets whenever they didn’t use their options. So, expired contracts ended up with no liquidity.
It cost $48K to fix the errors and provide impacted users with refunds.
4. Integer Overflow and Underflow
A Solidity smart contract is built using 256 bits which equates to 4.3 billion ether. However, any value above 256 resets to zero. And, any value below zero resets to 256. So, how does this smart contract vulnerability play out?
The attacker exploits a smart contract using a malicious address. He exploits the smart contract by making it look like the address has a maximum balance of 4.3 billion ether. Thus, the smart contract will allow withdrawals until it’s completely drained out of funds.
Real-life Example
What happened with the Proof of Week Hands coin is a good example of integer overflow and underflow. The project started as a Ponzi scheme but managed to gain over a million dollars.
Basically, the project allowed one person to approve another to transfer tokens on their behalf. So, an attacker allowed a second account to sell coins from the first account. But the coins were taken off the second account’s balance.
Again, if you set the value below zero, it resets to its maximum. As a result, the second account ended up with an insane balance of coins. This made the project lose $800K in just one night.
Currently, version 0.8.0 if the Solidity compiler no longer allows code that could lead to integer overflow and underflow. So, just check all smart contracts using the earlier versions to check for these issues. And, make sure to use the new version to avoid this.
5. Block Gas Limit Smart Contract Vulnerability
The Ethereum blockchain uses a block gas limit to make sure the block doesn’t grow too large. Basically, the amount of gas that transactions can use in a block is limited. So if a transaction consumes too much gas it will never go through. This leads to a Denial of Service (DoS) attack.
Real-life Example
An example of block gas limit smart contract vulnerability is the GovernMental case. In order to join the project, users had to pay a certain amount of ETH. But, the interested participants were too many that it required so much more gas than allowed leading to failure.
6. Timestamp Dependence
There’s a function called block.timestamp that lets smart contracts display StartTime and EndTime. Malicious hackers can manipulate this function for a few seconds and alter the output to their liking. This is why it’s better to avoid using this feature.
7. Force-feeding Attacks
These attacks take advantage of the fact that developers can’t keep a smart contract from receiving Ether. Therefore you can force-feed any contract ETH. This becomes a problem when a contract is set to give rewards if a balance increases above a certain level.
8. Missing Withdraw Functions
One of the common smart contract vulnerabilities is when your smart contract has a payable function but misses out on the withdrawing one. So you can only pay but you can’t retrieve your money. So, if you’re a sender your money is going to get locked within the smart contract.
How To Avoid These Smart Contract Vulnerabilities
Given their drastic consequences, smart contract vulnerabilities are of crucial importance. You should be aware of the top vulnerabilities in order to avoid them. But, how can you? You perform a smart contract audit. You can learn how to do that here. Good luck!