Insufficient Token Balance Validation Leading to Potential Fund Freezing or Contract Insolvency

[hats-bug-reporter[bot]]

Github username: @@BradMoonUESTC Twitter username: @xy9301 Submission hash (on-chain): 0xca4402fb76ad63702bcad1c0d1a6caa45c90b47a683fa0745eecaaa0abfdb753 Severity: high

Description: Description\ The provided code snippet from an AuraLocker contract reveals a significant vulnerability in the calculation of kick rewards, specifically focusing on the manner in which rewards are determined. The issue stems from the contract's logic, which incorrectly calculates the kick reward based on the amount of the user's last lock (locks[length - 1].amount) rather than the total locked balance. This flaw leads to the underpayment of kick rewards, as it fails to accurately represent the user's entire contribution to the locked funds over time. Such a discrepancy does not align with the intended incentive mechanisms designed within the system, undermining the fairness and effectiveness of the reward distribution process. This vulnerability falls under the category of "a contract failing to deliver promised returns," as it compromises the contract's ability to provide accurate kick rewards, potentially affecting user trust and participation.

Attack Scenario\ An attacker, in this context, could exploit this vulnerability by manipulating the timing of lock transactions to maximize their reward from the last locked amount, regardless of their total locked balance over time. This could potentially allow an attacker to unfairly increase their rewards at the expense of other users, who might not be aware of this exploit. The attack could involve a series of strategic lock and unlock operations, timed to exploit the flawed reward calculation during the evaluation of kick rewards.

Attachments

1. Proof of Concept (PoC) File https://github.com/hats-finance/Paladin-0x1610bfde27e57b068af7f38aec3d2a7b1d146989/blob/cf3c82f102a76f58acf003980c480eb9028f0e94/contracts/HolyPalPower.sol#L62-L77 A user locks a significant amount of tokens in the AuraLocker contract and subsequently performs minimal locks just before the reward calculation. Due to the vulnerability, the contract calculates the kick reward based on this minimal last lock amount, rather than the total locked balance. The attacker repeats this process across multiple epochs to maximize rewards.

The flaw can be demonstrated with the following simplified steps:

User A locks a large number of tokens. Just before the reward calculation, User A locks a minimal amount. The contract calculates the reward based on the minimal amount, ignoring the previously locked larger balance. User A receives a reward not reflective of their total contribution, illustrating the vulnerability.

[Kogaroshi]

Same as #73, looks invalid to me, as it is about AuraLocker once again, which is not managed in this codebase.