First Flight #3: Thunder Loan

Summary

There is no check to stop a malicious contract from manipulating the balance of the asset token by calling the deposit function during a flash loan.

Vulnerability Details

The deposit function is not checking if it is being called by the receiverAddress from the flashloan function. An attacker could drain funds by borrowing an amount of token via the flashloan function and then using the receiverAddress.functionCall to trigger the deposit function which would alter the state of the balance for the token during the same transaction without repaying it. The endingBalance check at the end of the flashloan function would pass and then the malicious contract would be able to redeem the tokens it deposited

Impact

All of the funds deposited in the ThunderLoan contract could be drained.

Tools Used

Recommendations

1. Add a state variable to keep track of addresses that are currently in the middle of a flash loan operation

2. Add a modifier that checks if the msg.sender is one of the addresses currently in the middle of a flash loan transaction

3. Apply the modifier to the deposit function so that the receiverAddress cannot call the deposit function to steal funds