First Flight #3: Thunder Loan

Summary

Burn asset tokens via bytes calldata params

Vulnerability Details

Address.functionCall will execute target.call{value: value}(data) using its context; implying it's executed directly by the Thunderloan in its context, which is dangerous for any access-controlled functions requiring onlyThunderLender. Thunderloan is manipulated to call any contract address, to execute any arbitrary function on that contract, with the permissions of Thunderloan.

Attacker can simply call flashloan

• borrowing 0 tokens;

• pass in receiverAddress as Asset Token address;

• pass in bytes calldata params that ensures its a payload that executes AssetToken.burn(address,amount) to burn an amount of asset token from their preferred address e.g

Impact

Attacker can use flashloan to burn asset token from someones account implying that account can no longer realize benefits of having deposited underlying asset into the protocol. Attacked account can potentially lose all the underlying token they put into protocol as their asset token used for redemption is burnt partially or completely

Tools Used

• Manual Analysis

• Damn Vulnerable DeFi Challenge Truster Solution => https://stermi.medium.com/damn-vulnerable-defi-challenge-3-solution-truster-7a4e00233ecd

Recommendations

• Enforce that receiverAddress implements IFlashLoanReceiver to reduce attack surfaces on arbitrary contract

• Recommended to call executeOperation directly and drop receiverAddress.functionCall(), just like how Aave does it e.g

• Extreme measure is to avoid passing in bytes calldata params which hinders the flexibility of flashloan to receiver but may be safer as its not rare to see flash loans implementing such simple formats
  Or any other such suitable measures to prevent this attack vector