The Standard

Summary

A critical vulnerability in the liquidationPoolManager smart contract allow a malicious actor to set an exceedingly high reward amount for all stackers, effectively creating a denial of service condition for the claimRewards function.

distributeAssets method, which should be restricted to execution by the liquidationPoolManager, is currently accessible to any user. The vulnerability arises from the lack of proper access control and validation of the _assets and _hundredPC parameters.

This would prevent legitimate users from claiming their rewards, while allowing the attacker to unilaterally claim all assets distributed after a liquidation event.

The exploit works by tampering with the system that decides how rewards are given out. It does this by feeding in forged information that distabilize the usual way of calculating rewards. This can lead to an unfair sharing of assets and could cause financial harm to users.

Vulnerability Details

To be able to run the test in this finding follow the following recommendation

As the distributeAssets method is external a malicious user could forge the following payload creating a DDOS for legitimate staker

Simple POC demo

distributeAssets bypass check walkthrough

By setting _hundredPC to zero the costInEuros variable will be qual to zero during the execution as a multiplication by zero is equal to zero

It allows the malicious actor to reward a large _portion of asset to other users as _portion is a ratio of the position stake, this amount will not be claimable as in this POC even 1% of the staking amount will represent 1000 ETH reward per users

Bellow are the most important manipulation during the execution.

As we are using ETH as asset and the amount of nativePurchased represent the maximum amount, returnUnpurchasedNative is 0.

So at then end of the POC each user will have an unreachable amount of reward set to their address, as we can see in the claimRewards method bellow, each attempt to claim will revert.

result when claiming:

Sophisticated POC to steal funds

In this POC a vault is created with ETH as collateral by the "user".
An other user Stake enough EUROs and TST to be able to claim assets in case of liquidation.

A malicious user block the legit staking user by providing him a huge amount of reward.

Then when a liquidation happen he set himself the amount of reward that should be sent to the user who stake.

The cost of the attack is 2 transactions and 2 wei of TST and EUROs.

Impact

The vulnerability in the distributeAssets method presents a severe risk, primarily due to the potential of a single malicious actor to exploit the system to their advantage while blocking other users from claiming their rewards. This can lead to several adverse outcomes:

1. Denial of Service for Legitimate Users: By manipulating the reward distribution, the attacker can set an unattainable amount of rewards for other users, effectively locking them out from claiming any rewards. This denial of service can erode trust in the platform and lead to a loss of user base.

2. Monopolization of Rewards: The attacker can position themselves as the only user capable of claiming rewards, allowing them to unfairly accumulate assets at the expense of other stakeholders in the ecosystem.

3. Economic Impact: Such an exploit could lead to significant financial loss for legitimate users and could potentially destabilize the economic model of the protocol, leading to broader systemic risks.

Tools Used

Forge test

Manual review

Recommendations

1. Access Control Restriction: Modify the distributeAssets method to ensure that it can only be called by the liquidationPoolManager. This can be achieved by implementing a modifier that checks the caller's address and compares it with the authorized liquidationPoolManager address.

2. Input Validation: Implement strict checks on the inputs to the distributeAssets method, particularly on _assets and _hundredPC parameters, to ensure they fall within reasonable and expected ranges. Additionally _hundredPC and _collateralRate could be called from the liquidationPoolManager

3. Rewards Calculation Logic Review: Re-examine and possibly refactor the logic used for calculating rewards in the claimRewards method to prevent overflow or underflow scenarios, which can be exploited.

4. Monitoring and Alerts: Establish monitoring systems to track unusual activities or transactions that could indicate attempts to exploit this vulnerability. Adding event in distributeAssets and claimRewards

5. Emergency Response Plan: Develop and maintain an emergency response plan to quickly address any exploitation attempts or security breaches related to this vulnerability.