Bad share accounting allows for sandwich attacks when WETH gets filled in as a reward for stakers

[codehawks-bot]

Bad share accounting allows for sandwich attacks when WETH gets filled in as a reward for stakers

Severity

High Risk

Relevant GitHub Links

https://github.com/Cyfrin/2023-07-beedle/blob/main/src/Staking.sol#L61

https://github.com/Cyfrin/2023-07-beedle/blob/main/src/Staking.sol#L68

Summary

The accounting algorithm used in the staking mechanism makes it possible for people to reap staking rewards by sandwiching the WETH-staking-rewards-adding transactions.

Vulnerability Details

The implementation of the algorithm used in deciding how much funds a user should get in the form of staking rewards has a fundamental flaw in its design: It increments a user's rewards not based on whether they have been staking for a certain amount of time or something similar, but on whether they have staked before or after a WETH fill up transaction.

// @audit it only calculates additional shares after a fill-up in the balance of WETH
uint256 _diff = _balance - balance;
if (_diff > 0) {
	uint256 _ratio = _diff * 1e18 / totalSupply;
	if (_ratio > 0) {
		index = index + _ratio;
	}
}

This opens the door for multiple vectors, one of which is sandwiching the staking rewards fill up transaction so you can get most of them for yourself. Here is a working PoC demonstrating how such a scenario might play out:

https://gist.github.com/CrisCodesCrap/7585f6c8ba32eb90b4f9a133c91ce5c7

Impact

A big amount of the funds allocated for stakers will be withdrawn by someone, who has just deposited and withdrawn tokens from the protocol.

Tools Used

Manual Review

Recommendations

Consider adding some sort of time parameter to the reward equation that cannot be gamed with frontrunning.