You can hardly find a more exploited vulnerability in Web3 than reentrancy. Older than Solidity itself, this type of cyberattack is technically in a whole different league from other security issues in DeFi. 

The word reentrancy stems from the sphere of general computing. Reentrancy occurs each time program execution is interrupted and gets restarted, with no errors visible even though both operations run completed. In DeFi, a reentrancy attack introduces flawed logic into smart contracts, sometimes leading to devastating losses.

Take the necessary steps to protect your project by undergoing a Smart Contract Audit.

That being said, not every reentrant behavior can be called a bug. It can turn into a critical security issue if two conditions are met:

• One contract calls another one while the former hasn’t updated its state yet. This can be accidentally enabled by adding a function that makes an external call to another untrusted contract before the state changes get executed.
• Once the malicious actor gains control over the untrusted contract, they can recursively call the original function over and over again, draining crypto wallets or sneaking into the code to make unsafe changes.

This is how an average reentrancy attack is launched step-by-step:

• The hacker builds a malicious smart contract.
• This contract is then used to call the target’s withdrawal function.
• Once the funds from the target have been received, a fallback function in the malicious smart contract is activated, repeatedly calling the withdraw function to get more funds. The target’s smart contract can’t update the attacker’s balance as the program flow is interrupted halfway.
• This process can go on multiple times until all the funds get stolen.

Well-known Reentrancy hacks

You’ll hear more stories about another one biting the dust due to reentrancy. How big can the losses be?  Let’s list some of the exploits of this kind that has been in the spotlight for the last few years:

• Uniswap/Lendf.Me lost $25 mln (April 2020) 
• The BurgerSwap lost $7.2 mln  (May 2021) 
• The SURGEBNB lost $4 mln (August 2021) 
• CREAM FINANCE lost $18.8 mln (August 2021) 
• Siren protocol lost $3.5 mln (September 2021) 
• Fei Protocol lost $80 mln (April 2022)

Still, the most notorious exploit using the reentrancy vulnerability happened on June 17, 2016, when a bad actor siphoned 3.6 mln ETH from TheDao’s smart contract (about 5% of all ETH at that time). Quite sophisticated, the attack involved creating a child DAO and calling several functions. The hacker managed to transfer funds to his personal wallet only 41 days later. In the meantime, the entire crypto community was discussing possible solutions. Eventually, these debates led to the creation of a hard fork of Ethereum that was named Ethereum Classic.

An example of reentrancy vulnerability revealed by Hacken

A possibility to re-enter the function for the message sender was detected during the audit of Colexion’s smart contracts. Provided someone initiated a transaction from the contract with a fallback function, they would be able to reenter the function repeatedly which presented a critical issue. The client was recommended to update the balance to zero before making the transaction. Status: Fixed

How can reentrancy attacks be prevented?

Reentrancy typically occurs across multiple functions or contracts, so preventing reentrancy within a single function is not enough. You have to finish all state changes before calling an external function.

1. The checks-effects-interactions design 

One of the ways to prevent reentrancy attacks is to use the checks-effects-interactions design while coding smart contracts. It requires structuring the functions in a certain order to make sure all state changes occur internally prior to calling external smart contracts.

2. Mutex

Not all contracts can be created using this design. In some cases, a mutex is used to render a certain function non-reentrant. This special modifier locks the current state so that any malicious attempts will be reverted at all times. As great as it may sound, mutex is far from being a universal solution. Unfortunately, it can severely limit platform capabilities, especially when it comes to multi-platform architecture. What’s more, coding with mutexes might bring about livelocks and deadlocks. 

3. Extensive audits

Even the best Solidity programmers make mistakes when working under tight deadlines. It is crucial for DeFi projects to get their smart contracts thoroughly checked by trusted Web3 cybersecurity auditors like Hacken.