You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Front-Running Attack Scenario:
If the attacker has access to the signature data, they could reproduce the signature's contents and stake before the legitimate transaction executes.
allows the attacker to see the components of the signature (amount, delegatee, claimer, etc.) before the transaction is mined, enabling them to create their own front-running transaction.
An attacker monitoring the network for incoming transactions can detect when a legitimate staking transaction is pending but has not yet been mined. This transaction will contain the signature, which provides the attacker with knowledge of the intended staking details.
The attacker can then craft a competing transaction with the same parameters (amount, delegatee, claimer, etc.) but with higher gas fees. This allows the attacker to prioritize their transaction and execute it before the legitimate transaction, effectively "front-running" the original user's stake.
Impact
The attacker could steal the staking action if they submit the transaction first with a higher gas fee, using the same signature and parameters, but gaining the governance influence or rewards that were intended for the legitimate depositor.
Governance manipulation: If the tokens staked are associated with governance voting, the attacker could skew voting outcomes.
Reward accrual manipulation: By staking before the original transaction, the attacker may receive rewards meant for the legitimate user.
PoC
PoC Code Snippet
// Attacker's transaction that front-runs the legitimate staking requestfunction attackFrontRun(
address_stakingContract,
uint256_amount,
address_delegatee,
address_claimer,
address_depositor,
uint256_deadline,
bytesmemory_signature
) external {
// The attacker submits the transaction to stake tokens before the legitimate depositorGovernanceStakerOnBehalf(_stakingContract).stakeOnBehalf(
_amount,
_delegatee, // Attacker assigns themselves as delegatee
_claimer, // Attacker claims the rewards
_depositor, // Original depositor's address (victim)
_deadline, // Same deadline as the legitimate transaction
_signature // Signature from the victim (exploited in this PoC)
);
}
Tool used
Manual Review
Recommendation
Mitigations to Consider
Non-repudiation and Signature Management:
Time-Limited Approvals:
Delay Before Execution:
Transaction Ordering Protection:
The text was updated successfully, but these errors were encountered:
Petite Slate Orangutan
High
Front-Running Attack on Signature Process in GovernanceStakerOnBehalf.sol
Summary
If the transaction is not yet mined, an attacker could monitor the mempool and detect the staking request. By submitting a competing transaction with a higher gas fee, the attacker could stake tokens before the legitimate transaction is processed
https://github.com/sherlock-audit/2024-11-tally/blob/main/govstaking/src/extensions/GovernanceStakerOnBehalf.sol#L71-L99
Vulnerability Detail
Front-Running Attack Scenario:
If the attacker has access to the signature data, they could reproduce the signature's contents and stake before the legitimate transaction executes.
Specifically, this line:
allows the attacker to see the components of the signature (amount, delegatee, claimer, etc.) before the transaction is mined, enabling them to create their own front-running transaction.
An attacker monitoring the network for incoming transactions can detect when a legitimate staking transaction is pending but has not yet been mined. This transaction will contain the signature, which provides the attacker with knowledge of the intended staking details.
The attacker can then craft a competing transaction with the same parameters (amount, delegatee, claimer, etc.) but with higher gas fees. This allows the attacker to prioritize their transaction and execute it before the legitimate transaction, effectively "front-running" the original user's stake.
Impact
The attacker could steal the staking action if they submit the transaction first with a higher gas fee, using the same signature and parameters, but gaining the governance influence or rewards that were intended for the legitimate depositor.
Governance manipulation: If the tokens staked are associated with governance voting, the attacker could skew voting outcomes.
Reward accrual manipulation: By staking before the original transaction, the attacker may receive rewards meant for the legitimate user.
PoC
PoC Code Snippet
Tool used
Manual Review
Recommendation
Mitigations to Consider
Non-repudiation and Signature Management:
Time-Limited Approvals:
Delay Before Execution:
Transaction Ordering Protection:
The text was updated successfully, but these errors were encountered: