Summary

https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/lstRewardsSplitter/LSTRewardsSplitterController.sol

The LSTRewardsSplitterController contract contains a vulnerability associated with the incorrect usage of the ERC677 safeApprove function, which allows for the granting of unlimited token allowances to the splitter contracts. This design choice poses significant security risks, potentially leading to unauthorized token withdrawals

Affedted Function:

addSplitter(address _account, LSTRewardsSplitter.Fee[] memory _fees)

Vulnerability Details

The contract uses IERC677(lst).safeApprove(splitter, type(uint256).max); to grant unlimited allowance to the newly created splitter. This approval is done without first resetting any previous allowances to zero.

Allowing unlimited approvals without checks creates a risk where a malicious actor could exploit this allowance to withdraw tokens without restrictions if they gain control of the splitter contract.

Example Scenario

1. Setup:

2. • Assume that the contract is deployed, and a splitter for account 0x123...abc is added using the addSplitter function. This splitter now has unlimited approval to transfer tokens from the LSTRewardsSplitterController contract.

3. Unlimited Allowance Vulnerability:

4. • If an attacker can somehow take control of the splitter contract (e.g., through an exploit, a compromised private key, or a misconfigured contract), they can withdraw any amount of tokens without limits.

   • For instance, the attacker calls the withdraw function of the splitter contract to transfer 500,000 LST tokens to their address.

5. Draining Funds:

6. • Given that there are no restrictions on the withdrawal amount due to the unlimited allowance, the attacker could potentially drain all available funds:

   function withdraw(uint256 _amount, address _receiver) external onlyController {
   principalDeposits -= _amount; // Decrease the principal deposits
   lst.safeTransfer(_receiver, _amount); // Transfer the specified amount to the attacker
   }

   • '''

7. If the splitter had a total balance of 1,000,000 LST tokens at the time of the attack, the attacker could execute this withdrawal without any restrictions, resulting in:

   • Attack Outcome: The attacker successfully transfers 500,000 LST tokens to their own address.

Impact

• With multiple splitter accounts being managed, a malicious actor could target any one of these splitters, especially if proper access controls are not enforced. The presence of unlimited approvals increases the attack surface significantly.

• If a malicious actor gains control of a splitter, they could execute an attack to drain all tokens available in that splitter.

  • For example, if a splitter holds 1,000,000 LST tokens, and the malicious actor exploits the vulnerability, they could transfer the entire balance to their own address without restriction, resulting in a direct financial loss of 1,000,000 LST tokens (worth potentially millions of dollars depending on market value).

Tools Used

Manual Review

Recommendations

Implement Allowance Management Best Practices:

• Always reset the allowance to zero before granting a new allowance

'''

IERC677(lst).safeApprove(splitter, 0); // Reset allowance
IERC677(lst).safeApprove(splitter, type(uint256).max); // Set new allowance

'''