Re-entrancy Attack

A re-entrancy attack is an attack that consists of an Attacker contract calling a Victim contract function in such a way that during execution the Victim calls the Attacker contract again, recursively. This can result, for example, in the theft of funds by skipping parts of the Victim contract that update balances or count withdrawal amounts.

A real-life example of a re-entrancy attack in the context of blockchain technology occurred in 2016, when an attacker exploited a flaw in Ethereum smart contract that was part of the decentralized autonomous organization (DAO) built on the Ethereum blockchain. The attack exploits a function in solidity called the Fallback Function. Please visit this article to understand more on fallback function.

Illustration on the re-entrancy attack that leads to Ethereum hard fork in 2016

The illustration above shows how the attack happened, and it all began when the hacker deploys a smart contract that has a fallback function called receive(). The hacker pretended to be an investor by depositing some Ether into the DAO. With this, the hacker is entitled to call a fallback function code called withdraw() from the DAO’s smart contract. The withdraw() function is triggered to send Ether to the hacker’s smart contract. When the hacker receives the funds, the receive() function is triggered to call the withdraw() function again from the DAO’s smart contract.

Since both functions were automatically triggering each other, it created an ongoing loop. The withdraw() function only stops when the hacker receive() function finishes – to update the hacker’s account balance – but it is instead re-called for another withdraw() that creates an unending cycle between both contracts.

Through this attack, the hacker was able to repeatedly call a specific function in the smart contract, allowing them to siphon off more than $50 million worth of Ether from the DAO's funds. This attack ultimately led to the creation of a new version of the Ethereum blockchain, known as Ethereum Classic, and highlighted the need for developers to carefully consider the potential risks of re-entrancy when designing smart contracts.

  • Faiz Adnan
Updated