The Standard

Summary

The function LiquidationPool::distributeAssets is assigned to distribute liquidated assets from a user's undercollateralized vault and is expected to be called by LiquidationPoolManager when a vault is liquidated with all the tokens that are accepted tokens as collateral.
But this function lags proper access control, resulting in unauthorized calling of the function with tokens that are not even accepted by the protocol thus leading to a huge loss of stakers position.

Vulnerability Details

The vulnerability lies inside the LiquidationPool contract at line 205 in the distributeAssets function due to mishandling of necessary access control checks as well as accepted tokens check.

The distributeAssets function is expected to be called from LiquidationPoolManager when a user's vault is liquidated which takes in _assets, collateralRate and _hundredPC, but due to missing access control checks it can be invoked by an attacker with fake tokens which can lead to burning of the whole amount of EUROs from all the stakers of the protocol. Thus, giving attacker the whole amount of EUROs that was staked in the protocol.

Along with that, if only NATIVE token (eth) is passed inside the _asset array parameter without actually paying the eth while calling the function will lead to mismanagement of the rewards mapping as the staker's reward will be increased but eth was not sent inside the LiquidationPool contract thus with this vulnerability attacker can drain the assets.

As well as if they pass a token with address(0) and with symbol of any of the accepted token then due to its address as adress(0) the protocol will consider it as a native token and will keep on increasing the user's rewards without actually increasing the LiquidationPool's corresponding balance of that token inside it. Thus, potentially type(uint256).max value can be supplied with that asset along with an address for chainlink address field which returns very cheaper value and it will make staker's rewards reach to very high value and the value of an individual's rewards can potentially exceed the actual asset balance of LiquidationPool. As a result of which LiquidationPool asset balance can be potentially drained by an attacker.

Thus an attacker can create deficiency of tokens inside the LiquidationPool as the rewards of user's were increased but the corresponding balance of the LiquidationPool was not increased for that token thus creating mismanagement of rewards.

Impact

Attacker can potentially:

1. Drain the EUROs position of all stakers.

2. Create a deficiency of tokens inside the LiquidationPool as the reward was updated but corresponding balance was not increased for that token. Thus the attacker can prevent other users from redeeming their rewards and even cause drain of all collateral asset balance of LiquidationPool.

PoC

Setup for the test:

Create a fake token contract: FraudBTCToken.sol

Create a new folder name it attackToken inside contracts and create the solidity file: FraudBTCToken.sol with the following contract

Add the test in the file: test/liquidationPool.js

Run both the tests by:

Tools Used

Manual Review

Recommendations

Add the necesary access control on the LiquidationPool::distributeAssets function for only the LiquidationPoolManager can invoke it.