Summary:

The getReward function in the smart contract allows any external caller to claim rewards on behalf of any staker by specifying the staker's address and reward index. The function lacks proper authorization checks to ensure that only the legitimate staker or an authorized entity can initiate the reward claim process.

Vulnerability Details:

Any can call getReward function pass a other staker address claim reward on behalf of stker even if amount is transfer into staker but it gives unauthorized access to call anyone

Impact:

This vulnerability allows unauthorized users to call the getReward function and trigger the reward distribution process for any staker. While the rewards are still credited to the legitimate staker, the lack of access control can lead to potential front-running or griefing attacks where an attacker can interfere with the timing of reward claims.

Level:

Medium

Proof of Concept/Explanation:

1. Contract Snippet:

   function getReward(address staker, uint256 index) external override updateReward(staker, index) {

   _getReward(staker, staker, index);

   }

   ​

   function _getReward(address staker, address rewardsToAddress, uint256 index) internal {

   uint256 amount = claimableRewards[staker][index];

   if (amount > 0) {

   claimableRewards[staker][index] = 0;

   rewardToken.safeTransfer(rewardsToAddress, amount);

   emit RewardPaid(staker, rewardsToAddress, index, amount);

   }

   }

2. Exploit Scenario:

   • Assume attacker wants to interfere with staker1's reward claims.

   • attacker calls the getReward function using staker1's address and the appropriate reward index:

     contractInstance.getReward(staker1, index);

   • The function executes and triggers the reward distribution for staker1 without any authorization check on attacker.

   • While the reward is still transferred to staker1, the timing of the claim can be disrupted, causing potential issues with reward scheduling or transaction costs.

Tools Used:

Manual, Foundry

Recommendations:

To mitigate this vulnerability, implement an authorization mechanism that ensures only the staker or an explicitly authorized entity can initiate the reward claim process. Below is an example of how this can be achieved:

1. Authorization Mapping and Modifier:

   mapping(address => mapping(address => bool)) public authorizedCallers;

   ​

   modifier onlyAuthorized(address staker) {

   require(staker == msg.sender || authorizedCallers[staker][msg.sender], "Caller not authorized");

   _;

   }

2. Updated getReward Function:

   function getReward(address staker, uint256 index) external override updateReward(staker, index) onlyAuthorized(staker) {

   _getReward(staker, staker, index);

   }

   ​

   function authorizeCaller(address _caller) external {

   authorizedCallers[msg.sender][_caller] = true;

   }

   ​

   function revokeCaller(address _caller) external {

   authorizedCallers[msg.sender][_caller] = false;

   }

3. Explanation:

   • The onlyAuthorized modifier checks if the caller is either the staker themselves or an authorized entity.

   • The authorizeCaller and revokeCaller functions allow stakers to manage which addresses are authorized to claim rewards on their behalf.

   • This ensures that only legitimate and authorized calls to getReward are processed, preventing unauthorized interference.