First Flight #3: Thunder Loan

Summary

Manipulate exchange rate to explode 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.updateExchangeRate(amount) in order to update exchange rate to become much higher

Impact

Attacker can use flashloan to call updateExchangeRate() on AssetToken, this result in the exchange rate increasing as they desire or exploding if they enter a large value for fee. The new manipulated fee will affect the exchange between underlying tokens and exchange tokens leading to more gains for attacker. An argument could be attacker may pay large fee if they input large fee. However in other attacks we see how attacker can easily make up for the fee or attack with various inputs to obtain varied results.

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

• Enforce amount != 0

• 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 suitable ways and methods to avoid such attack vector