The Standard

Summary

The function to distribute assets has no access control modifier which could allow a user to drain funds from the protocol by providing their own modified assets array.

Vulnerability Details

In LiquidationPool.sol a malicious user with an active stake can provide their own input parameters, however to make them effective a few modifications are necessary first

LiquidationPoolManager.Asset[] memory _assets

the _assets[index].amount would have to be greater than zero, then the _asset[index].token.dec, _hundredPC and _collateralRate input parameters will have to be modified in such a way that the user can gain a maximum _portion. This is to gain maximum possible rewards:

rewards[abi.encodePacked(_position.holder, asset.token.symbol)] += _portion

However, the complexity arises in that the total asset amount has to be equal to the native purchased variable which is the sum of all the portions in order to bypass the line

(bool _sent,) = manager.call{value: _assets[index].amount - _nativePurchased}("");

The best condition for an attacker in this case is if all holders have staked euro token that is greater than zero then they could set the _asset[index].token.dec value to 18 in order to ensure

uint256 costInEuros = _portion * 10 ** (18 - asset.token.dec) * uint256(assetPriceUsd) / uint256(priceEurUsd)
* _hundredPC / _collateralRate;

costInEuros equates to zero and this will allow the asset amount to be equal to all the portions staked. However if this is not the case, then modifying the costInEuros variable to get an equilibrium between _assets[index].amount and nativePurchased is highly unlikely to be efficient due to third party oracles but theroretically possible.

The last possible but highly likely situation is if there are already unclaimed native assets in the protocol this could make this much easier for an attacker.

The other requirement is

_assets[index].token.addr

will have to be equal to address(0) to bypass token transfers and

_assets[index].token.symbol

will have to be equal to Native token symbol.

Once a user has inflated the rewards they can then proceed to claim rewards, this attack can be run as many times as possible.

Impact

This is attack could be disastrous, in that users will constantly have changing rewards and a single malicious actor can drain all other users rewards until the protocol is insolvent.

Tools Used

Manual Review

Recommendations

I would recommend an access control modifier that allow only the LiquidationPoolManager.sol to call this function.