Tapioca DAO - ayeslick's results

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/bigBang/BigBang.sol#L288 https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/Singularity.sol#L235

Vulnerability details

Impact

The allowedBorrow() modifier on the addCollateral() checks if msg.sender is allowed to interact on from’s behalf via an allowanceBorrow mapping located in the MarketERC20 contract. If so _addCollateral() is called. An if statement checks if share is zero if so it sets share to the value returned by the call to yieldBox.toShare where amount is used.

An operator can set share to zero which passes the check in the allowedBorrow() modifier since 0 isn’t greater than 0. An operator can set amount to a number that doesn’t exceed the amount of collateral from has. When _addCollateral() sees that share == 0 it will set share to the value returned from yieldBox.toShare using amount passed in by the operator. From here share is added to the operator’s address and then deducted from from. The operator can then withdraw this collateral via removeCollateral().

Proof of Concept

Operator calls addCollateral setting to to an address he controls, from to a customer, amount to an amount from has, and share to zero.

Operator bypasses the allowedBorrow modifier with share set to zero.

In _addCollateral attackers share is adjusted by yieldBox.toShare using the amount the operator passed in

Share is added to the operator

Share is deducted from customer

Operator then calls removeCollateral with share matching the share he just received

Operator receives collateral

Tools Used

manual

Recommended Mitigation Steps

Remove amount variable.

OR

Don’t allow share to be zero.

Assessed type

Other

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/usd0/USDO.sol#L88

Vulnerability details

Impact

Based on the name, maxFlashLoan(), one assumes the goal is to prevent customers from obtaining too much, >maxFlashMint, USDO via flashMint() for a given transaction. However, when onFlashLoan() is called on the receiver contract it can call flashLoan() again to receive more tokens beyond maxFlashMint.

This is because maxFlashLoan() checks if amount is greater than maxFlashMint not if the total amount the receiver has minted is >maxFlashMint.

Proof of Concept

1. Customer calls flashLoan()
2. onFlashLoan is called on the Customers' receiver contract
3. Customers' receiver contract calls flashLoan() again
4. Customer receives additional USDO tokens beyond the maxFlashMint.

contract ReceiverContract {
    ITapiocaFlashLoan public tapioca;
    uint256 public loop;

    constructor(address _tapioca) {
        tapioca = ITapiocaFlashLoan(_tapioca);
    }

    function initiateFlashLoan(uint256 amount) public {
        tapioca.flashLoan(address(this), amount);
    }

    function onFlashLoan(uint256 amount) external {
        ++loop;
        if (loop < 3) { 
            tapioca.flashLoan(address(this), amount);
        }
        // Logic to handle the flash loan
    }
}

Tools Used

manual

Recommended Mitigation Steps

In the maxLoan() do the following: if (totalSupply() + amount > maxFlashMint) revert();

Assessed type

Other

Lines of code

https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/aave/AaveStrategy.sol#L192 https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/curve/TricryptoNativeStrategy.sol#L169 https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/convex/ConvexTricryptoStrategy.sol#L206 https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/curve/TricryptoLPStrategy.sol#L178

Vulnerability details

Impact

When swapper.getOutputAmount is reached swapData and a blank string, "", are passed. CurveSwappers’ getOutputAmount expects dexOptions to be an array of uint256, not a blank string, “”. As a result, the transaction will revert which will prevent these strategies from compounding.

Proof of Concept

1. Aave strategy is deployed with CurveSwapper as its swapper
2. A caller calls compound but the transaction reverts

Tools Used

manual

Recommended Mitigation Steps

If CurveSwapper ensure that the correct parameters are passed

Assessed type

DoS

Lines of code

https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/master/contracts/markets/singularity/Singularity.sol#L277

Vulnerability details

Impact

Singularity, Penrose, and USDO implement a pause feature that when it's activated prevents customers from taking any actions. This can negatively impact a customer who is close to liquidation when a pause occurs. It is possible that by the time the pause ends, the customer's position will be liquidatable. As such, unless the customer has an MEV liquidation bot that beats out other bots to repay his debt before they liquidate his position. Running such a bot seems like a high barrier to set for customers.

Proof of Concept

1. Customer takes out a position
2. Customer is close to liquidation
3. Before the Customer repays his debt the protocol is paused
4. During the interim the Customer's position is liquidatable
5. When the pause is lifted an MEV bot liquidates the Customer's position before he has a chance to repay

Tools Used

manual

Recommended Mitigation Steps

Implement a method(s) that smoothly transitions the accumulated changes over time rather than applying them all at once when the contract is unpaused. If possible, take a snapshot of the relevant state variables at the time of pausing, and restore that snapshot when unpausing, followed by a gradual adjustment to the current state.

Assessed type

Other

Lines of code

https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/aave/AaveStrategy.sol#L192 https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/curve/TricryptoLPStrategy.sol#L178 https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/curve/TricryptoNativeStrategy.sol#L169 https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/master/contracts/convex/ConvexTricryptoStrategy.sol#L206

Vulnerability details

Impact

If swapper uses UniswapV2Swapper then calcAmount is determined by calling the getAmountsOut() on the UniswapV2 router, resulting in a spot price at that specific moment. This can allow an MEV bot to strategically place transactions around a call to the compound(). By front-running the call, the bot can manipulate the price, and then by back-running, it can further exploit the price difference.

Proof of Concept

1. The AaveStrategy contract holds a large amount of tokens
2. The operator unbalances the liquidity pool by executing trades or other operations
3. The operator calls compound which sets minAmount to the higher amount
4. After the call to compound completes, the operator rebalances the liquidity pool.

Tools Used

manual

Recommended Mitigation Steps

Use TWAP instead of spot pricing.

Assessed type

MEV