Damn Vulnerable DeFi Write-Up

Introduction

I recently completed the Damn Vulnerable DeFi set of challenges. These challenges makes a good break-in into the EVM smart-contract auditing world. With this write-up I hope to provide some insight about the challenges bugs. I also want to highlight some quirks and oddities about the dev environments and frameworks.

The challenges have been updated and 4 levels have been added in November 2021: this write-up is about the updated version, so you’ll have no problem about copy-pasting solutions. However, if you haven’t completed the challenges I advise you to go try them yourself and come after. All you should need is the Solidity documentation and Ethers documentation. If you struggle with your exploit implementation once you found a bug and an exploitation route, looking at a solution is ok but you get most value of these challenges by solving them on your own and looking at anyone else solution afterwards. I want to highlight challenges number 4, 6, 11 and 12 as the most interesting ones.

The development environment is based around Hardhat: it seems to be the most recent and complete library in the field. One of the best feature is logging which is described here.

Challenge 1: Unstoppable

In this challenge you have to trigger a DoS vulnerability. Reading the code should makes you wonder if the check highlighted below isn’t too strict and what would happen if you graciously send the pool 1 DVT token…

function flashLoan(uint256 borrowAmount) external nonReentrant {
    require(borrowAmount > 0, "Must borrow at least one token");

    uint256 balanceBefore = damnValuableToken.balanceOf(address(this));
    require(balanceBefore >= borrowAmount, "Not enough tokens in pool");

    // Ensured by the protocol via the `depositTokens` function
    assert(poolBalance == balanceBefore);
    
    damnValuableToken.transfer(msg.sender, borrowAmount);
    
    IReceiver(msg.sender).receiveTokens(address(damnValuableToken), borrowAmount);
    
    uint256 balanceAfter = damnValuableToken.balanceOf(address(this));
    require(balanceAfter >= balanceBefore, "Flash loan hasn't been paid back");
}

Here is how to do it:

await this.token.connect(attacker).transfer(this.pool.address, 1);

• See challenge contracts
• See deploy and exploit JS code

Challenge 2: Naive receiver

In this challenge a pool interacts with a receiver contract. The pool contract can only interact with contracts implementing the receiveEther(uint256) function but anyone can make an eligible contract borrow money: that’s what we do in the NaiveReceiverAttacker contract below.

To mitigate this issue either the the pool should include a mechanism to not allow anyone to make an eligible contract borrow money or the receiving contract should check where the borrow originates from (easily done by using tx.origin). Another solution could be to allow only the receiver contract to call the flashLoan function and ditch the borrower parameter. Solutions are not missing, it’s just that NaiveReceiverLenderPool has a truly flawed design.

contract NaiveReceiverAttacker {
    function attack(address borrower, address payable lenderpool) external {
        NaiveReceiverLenderPool pool = NaiveReceiverLenderPool(lenderpool);
        // Receiver has 10 ETH: do 10 0 eth loans to drain his account by
        // forcing him to pay fees
        for(uint i=0; i<10; i++) {
            pool.flashLoan(borrower, 0);
        }
    }
}

Deploying a contract is only 2 lines of Javascript code; calling our exploit function is straight forwards:

const NaiveReceiverAttacker = await ethers.getContractFactory('NaiveReceiverAttacker', attacker);
var attack_contract = await NaiveReceiverAttacker.deploy();
await attack_contract.attack(this.receiver.address, this.pool.address);

We deployed the contract as attacker so we don’t need to explicitly connect to it: the default Signer will be the deployer.

• See challenge contracts
• See deploy and exploit JS code
• See exploit contract

Challenge 3: Truster

In this challenge we face a loan contract whose flashLoan(uint256 borrowAmount, address borrower, address target, bytes calldata data) prototype looks shady: we can provide target and data which will be called by the contract during the loan. As we can choose the target we choose to call the DVT contract to approve ourself to transfer the tokens: here is the code of the attacker contract.

Here the design flaw is to allow any target to be called: only the contract asking fo the loan should be allowed to be called back. Reentrancy should also be taken into account but looking at challenge titles it seems to be the subject of the next one.

• See challenge contract
• See deploy and exploit JS code
• See exploit contract

Challenge 4: Side entrance

This flash loan pool seems to have better design than in the last challenge: here the execute function of the loaner is executed and handed the flash loan.

1function flashLoan(uint256 amount) external {
2    uint256 balanceBefore = address(this).balance;
3    require(balanceBefore >= amount, "Not enough ETH in balance");
4    
5    IFlashLoanEtherReceiver(msg.sender).execute{value: amount}();
6
7    require(address(this).balance >= balanceBefore, "Flash loan hasn't been paid back");        
8}

The loaner is handed some money on line 5, then if the money isn’t sent back the require statement line 7 will fail and the transaction will be reverted. Nothing bad could happen right ? Someone thinking that could not be more wrong: sneaky as we are we will send back the money not with the classic transfer function but by calling the deposit function and increasing our balance so it equals the entire pool money. Then, in the same transaction we can withdraw our ETH and empty the pool: the challenge is completed.

What is the flaw in the contract ? We reentered the contract after getting our flash loan and managed to modify its state to our advantage: this is a classic reentrancy bug. The first three challenges were not very realistic situations but this one shows a vulnerability pattern you can encounter in the real world: the infamous DAO hack is based on a reentrancy exploit.

• See challenge contract
• See deploy and exploit JS code
• See exploit contract

Challenge 5: The rewarder

The rewarder pool from this challenge give rewards base on who is holding token when the deposit function is called. We can then leverage a flash loan to deposit money only during one round and as long as we didn’t already claimed reward for the current round, we will receive rewards.

• See challenge contracts
• See deploy and exploit JS code
• See exploit contract

Challenge 6: Selfie

The pool have a function which seems very interesting: drainAllFunds(address receiver) but calling it is restricted by the onlyGovernance modifier.

The OpenZeppelin documentation on ERC20Snapshot mentions than allowing anyone to call _snapshot can be used by attackers. It does not explicit the bug we are facing: in this challenge we can create a snapshot while holding tokens from a flash loan: triggering a snapshot and queuing an action calling to drainAllFunds is then all it takes to beat this challenge. Then we have to wait for at least 2 days to execute the action.

Developing this exploit took me quite some time because we need to read blockchain events to retrieve the action id in an event emitted by queueAction in the SimpleGovernance contract. There is one subtlety here: because we are calling our own contract, ethers.js will not be aware of the event ABI of the SimpleGovernance contract. We could get around this by for instance emitting our own event in the attacking contract or by filtering through all blocks. I find the cleanest way of doing it is to add the events we want to parse in the attacking contract ABI: this is the solution chosen in my code but there also is a commented alternative method.

• See challenge contracts
• See deploy and exploit JS code
• See exploit contract

Challenge 7: Compromised

Analyzing the HTTP capture with a tool like CyberChef expose two Ethereum private keys allowing us to send transaction as two of the three oracles. We can thus set the price we want as the median price is used. Getting the money is just a matter of using the Exchange contract.

• See challenge contracts
• See deploy and exploit JS code

Challenge 8: Puppet

We are facing a lending pool and an Uniswap v1 pair. Change rate is calculated with a very simple formula:

function _computeOraclePrice() private view returns (uint256) {
    // calculates the price of the token in wei according to Uniswap pair
    return uniswapPair.balance * (10 ** 18) / token.balanceOf(uniswapPair);
}

The lending pool is using this rate to provide loans where we have to provide twice the collateral. If the Uniswap pair ETH balance is close to zero then the rate is going to be very low. Luckily we have more ETH and DVT than the Uniswap pair so we can manipulate the price: we swap DVT for ETH so the pool has almost no ETH left: we can now borrow DVT to the pool at a very interesting rate.

• See challenge contract
• See deploy and exploit JS code

Challenge 9: Puppet v2

This challenge is called Puppet v2 because it upgrade the Uniswap pair to v2 but apparently the pool developer did not read the oracle part of the documentation: we process the same as for previous challenge except for the increased boilerplate code.

• See challenge contract
• See deploy and exploit JS code

Challenge 10: Free rider

The vulnerability in this challenge is trivial to spot: the developer thought than on line 13 the contract would send tokens to the seller but it sends money to the new owner: the NFT has been transferred on line 11 !

 1function _buyOne(uint256 tokenId) private {
 2    uint256 priceToPay = offers[tokenId];
 3    require(priceToPay > 0, "Token is not being offered");
 4
 5    require(msg.value >= priceToPay, "Amount paid is not enough");
 6
 7    amountOfOffers--;
 8
 9    // transfer from seller to buyer
10    token.safeTransferFrom(token.ownerOf(tokenId), msg.sender, tokenId);
11
12    // pay seller
13    payable(token.ownerOf(tokenId)).sendValue(priceToPay);
14
15    emit NFTBought(msg.sender, tokenId, priceToPay);
16}

We can use the deployed uniswap exchange to get a flash loan (here called flash swap) to get the required liquidity: the difficulty of this challenge resides in implementation.

• See challenge contracts
• See deploy and exploit JS code
• See exploit contract

Challenge 11: Backdoor

Interacting with Gnosis Safe Wallets is perhaps less documented than the Uniswap protocol for instance, and was definitely more confusing to me. So I started by implementing the interactions the developer expected to happen:

let userAddresses = users;
let userSigners = [alice, bob, charlie, david];
for (let i = 0; i < userAddresses.length; i++) {
    var initCode = this.masterCopy.interface.encodeFunctionData("setup", [
        [userAddresses[i]],                 // _owners
        1,                                  // _threshold
        ethers.constants.AddressZero,       // to (optional delegateCall)
        [],                                 // data (optional delegateCall)
        ethers.constants.AddressZero,       // fallbackHandler
        this.token.address,                 // paymentToken
        0,                                  // payment
        ethers.constants.AddressZero        // paymentReceiver
    ]);

    await this.walletFactory.connect(userSigners[i]).createProxyWithCallback(
        this.masterCopy.address,
        initCode,
        0,
        this.walletRegistry.address
    );
}
const wallet = await this.walletRegistry.wallets(alice.address);
const balance = await this.token.balanceOf(wallet);
console.log("Alice balance: %s DVT", ethers.utils.formatEther(balance));

The following proxyCreated function is called upon creation on a wallet.

 1function proxyCreated(
 2    GnosisSafeProxy proxy,
 3    address singleton,
 4    bytes calldata initializer,
 5    uint256
 6) external override {
 7    // Make sure we have enough DVT to pay
 8    require(token.balanceOf(address(this)) >= TOKEN_PAYMENT, "Not enough funds to pay");
 9
10    address payable walletAddress = payable(proxy);
11
12    // Ensure correct factory and master copy
13    require(msg.sender == walletFactory, "Caller must be factory");
14    require(singleton == masterCopy, "Fake mastercopy used");
15    
16    // Ensure initial calldata was a call to `GnosisSafe::setup`
17    require(bytes4(initializer[:4]) == GnosisSafe.setup.selector, "Wrong initialization");
18
19    // Ensure wallet initialization is the expected
20    require(GnosisSafe(walletAddress).getThreshold() == MAX_THRESHOLD, "Invalid threshold");
21    require(GnosisSafe(walletAddress).getOwners().length == MAX_OWNERS, "Invalid number of owners");       
22
23    // Ensure the owner is a registered beneficiary
24    address walletOwner = GnosisSafe(walletAddress).getOwners()[0];
25
26    require(beneficiaries[walletOwner], "Owner is not registered as beneficiary");
27
28    // Remove owner as beneficiary
29    _removeBeneficiary(walletOwner);
30
31    // Register the wallet under the owner's address
32    wallets[walletOwner] = walletAddress;
33
34    // Pay tokens to the newly created wallet
35    token.transfer(walletAddress, TOKEN_PAYMENT);        
36}

We understand than if Alice (or any walletOwner) creates a wallet in their name they will be rewarded 10 DVT. Understanding how Gnosis Safe wallets works the first idea is to add several owners to the wallet to allow us to have access to the reward. Unfortunately the wallet registry is configured as such as the checks on line 20 and 21 are preventing us to do so. Let’s look again at which parameters are available to us in the GnosisSafe::setup function: to and data allow us to delegatecall into anything we want ! If we delegatecall into code approving us to transfer tokens we can call transferFrom as the attacker.

• See challenge contract
• See deploy and exploit JS code
• See exploit contract

Challenge 12: Climber

In the set of contracts the challenge gives us we have a pool following the UUPS pattern. This pattern is described in the linked EIP-1822. We also see than the vault contract is using the OpenZeppelin implementation UUPSUpgradeable. In the UUPSUpgradeable code we see that the contract is also conforming to EIP-1967.

In fact, the first EIP describes the mechanism while storage slots are defined in the second one.

In the documentation we notice an interesting warning: « Using upgradeable proxies correctly and securely is a difficult task that requires deep knowledge of the proxy pattern, Solidity, and the EVM ». This definitely looks like where the vulnerability will be !

 1/** Anyone can execute what has been scheduled via `schedule` */
 2function execute(
 3    address[] calldata targets,
 4    uint256[] calldata values,
 5    bytes[] calldata dataElements,
 6    bytes32 salt
 7) external payable {
 8    require(targets.length > 0, "Must provide at least one target");
 9    require(targets.length == values.length);
10    require(targets.length == dataElements.length);
11
12    bytes32 id = getOperationId(targets, values, dataElements, salt);
13
14    for (uint8 i = 0; i < targets.length; i++) {
15        targets[i].functionCallWithValue(dataElements[i], values[i]);
16    }
17    
18    require(getOperationState(id) == OperationState.ReadyForExecution);
19    operations[id].executed = true;
20}

The only interesting entry point accessible without any specific role is execute function in ClimberTimelock. We notice the function is checking if the executed operations were scheduled line 18 after executing them. The transaction will be reversed if the check fails but maybe we can somehow get the check to pass while we control execution flow in the for loop lines 14-16. To reduce this attack surface all smart contract developers should always use the Checks-Effects-Interactions pattern.

Let’s now look at the different permissions and roles in these two contracts. The vault is owned by the timelock contract and can only be upgraded (following the UUPS EIP) by the latter. Two roles are defined (using OpenZeppelin AccessControl library): ADMIN_ROLE and PROPOSER_ROLE. ADMIN_ROLE is unused: the challenge is probably built from a real world example and some functions have been stripped. This makes our research easier because we now only have to look at the schedule( function which is restricted

What is the plan then ? We will call the execute function with arguments that makes it execute two calls: the first one to allow the vault to have the PROPOSER_ROLE and the second one to upgrade the vault to a contract specially crafted by us. This contract will then schedule the operations we are currently executing and send all funds from the vault to us. Implementation-wise the interesting bits are:

• encoding the same calls in both the transaction (attacker calling execute(...)) and the exploit contract (calling schedule(...))
• correctly understanding the UUPS mechanism.

I will not detail the exploit further and let you look at the commented code in my repo. Please note than they are many different ways to exploit this vulnerability even though always relying on the fact than someone can hijack the execution flow to their advantage in the execute function.

• See challenge contracts
• See deploy and exploit JS code
• See exploit contract

Conclusion

All the vulnerabilities present in these challenges comes could have been avoided by reading the numerous warnings in Solidity and OpenZeppelin documentations, respecting safe Solidity patterns and developing contracts more carefully. The latter is easier said than done thus leading to infamous hacks (see for instance this leaderboard) and bounties (see for instance Immunefi blog). In real life, exploitation is trickier with balance requirements, mempool transaction stealing and lawfulness of your actions. Fortunately the bug bounty culture of the DeFi space is very advantageous to the honest researcher: I encourage you to check out some of the rewards on Immunefi. Happy hacking !