INIT Capital Invitational - rvierdiiev's results

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L191-L195

Vulnerability details

Proof of Concept

Using setPosMode function owner of position can change it's mode. When the function is called, then there are a lot of checks, like if current mode allows to decollateralize and if new mode allows to collateralize.

Also it's checked, that all position collateral is used by the new mode. It's done for the pools and for the wLp tokens.

In order to be able to use wLp tokens as collateral, then wLp should be whitelisted. It is checked in several places in the code, like here. It's also possible that after some time wLp token will be blacklisted. In this case it should not be allowed to migrate blacklisted wLp token to the new mode, however there is no such check in the setPosMode function.

As result user can provide blacklisted collateral to the new mode. I understand that borrowing factor for such collateral will be likely about 0, however if you would try to collateralize such token, then it will be denied, thus setMode function breaks this invariant.

Impact

Non whitelisted collateral can be moved to the new mode.

Tools Used

VsCode

Recommended Mitigation Steps

Do not allow user to move blacklisted collateral to the new mode.

Assessed type

Error

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/hook/MoneyMarketHook.sol#L76-L80

Vulnerability details

Proof of Concept

MoneyMarketHook allows user to chain some actions into one multicall to the InitCore. In the end user can get all wrapped native tokens that he withdrew in a form of native token. Note, that this part of code withdraws all balance from wrapped token and the sends all balance to the msg.sender. In case if balance of contract is 0, then the call will still succeed.

One type of actions that caller can do using execute function is withdraw. In case if caller needs to repay funds to other address then he can provide it as to param. So as result, IInitCore.burnTo will transfer pool tokens to the provided recipient. And in case if token has a hook, like erc777 or erc677, then receiver will be triggered and he has execution control now.

User can have multiple withdraws in same multicall. And it's possible that first withdraw is wrapped native token withdraw(which user would like to receive as native) and next withdraw is with erc777 token and other recipient.

In such case, when first withdraw is done, then wrapped token is already on MoneyMarketHook balance. And then when second withdraw is handled and attacker get hook, then he can call MoneyMarketHook.execute(it doesn't have reentrancy check) again with any params that just should pass and _params.returnNative as true. Then all wrapped token balance will be sent to the attacker and then execution will return back to the victim and it will send 0 amount as native token to the victim.

As result attacker is able to steal user's native tokens.

From readme it's clear that only fee on transfer tokens are not supported and erc777 are supported:

Please list specific ERC20 that your protocol is anticipated to interact with. Could be "any" (literally anything, fee on transfer tokens, ERC777 tokens and so forth) or a list of tokens you envision using on launch. No fee-on-transfer tokens

Impact

It's possible to steal user's funds.

Tools Used

VsCode

Recommended Mitigation Steps

Add reentrancy check to the execute function.

Assessed type

Error

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L535

Vulnerability details

Proof of Concept

TRST-M-8 from previous audit describes the fact, that when repaying is paused, then pool still continue accruing interests. Usually this is not considered as a medium bug anymore. However, protocol team has stated, that they have fixed everything.

I should say, that TRST-M-8 still exists and in case i repayment will be paused and user will not be able to reduce their debt, their debt shares will continue to accrue interest.

Impact

Interest accruing is not paused, when repaying is not allowed.

Tools Used

VsCode

Recommended Mitigation Steps

You can implement the logic that will pause all interest accruing as well, but i am not sure this is indeed needed.

Assessed type

Error

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L275

Vulnerability details

Proof of Concept

When users deposit wLP tokens as collateral, then they are checked to be whitelisted.

Later, it's possible that for some reason wLP token will be backlisted by governor. And once it's done, then users, who already used that wLP tokens as collateral will not be able to withdraw them.

Also same thing exists for the liquidateWLp function, which means that in case if position, that is collateralized with wLP that is blacklisted, will become unhealthy, then liquidators will not be able to liquidate it.

Sponsor said that blacklisting flow will be as following.

• Decrease collateral factor for blacklisted wLp until it becomes 0
• then blacklist wLp

Considering this fact i realize that for liquidation this will not be an issue as wLp will have 0 collateralization power when it will be blacklisted. However it's still possible that some user will not decollateralize their wLp tokens yet for some reasom and thus they will not be able to withdraw them later.

Impact

User can't withdraw previously deposited wLP tokens after they were blacklisted.

Tools Used

VsCode

Recommended Mitigation Steps

Even if wLP token is backlisted now, you still should allow user to withdraw them. After all you have health check function that will guarantee that position has enough collateral.

Assessed type

Error

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L288

Vulnerability details

Proof of Concept

In case if borrower's position is unhealthy, then he can be liquidated. Liquidator can provide amount of shares in _poolToRepay that he will cover and expects to get back _poolOut shares. It is possible that position created a bad debt. This means that amount that position has borrowed is bigger than supplied collateral.

In this case only part of debt of the positon will be repaid to lenders by liquidator. Let's check what that means for the pool.

When burn is called, then _toAmt is called to calculate amount that user can receive for his shares. It uses cash + totalDebt and totalSupply to calculate it. totalDebt is all borrowed amount that is not repaid yet. So contract expects that all borrowed amount will be repaid eventually.

So in case if bad debt occurs it means that part of borrowed amount will not be received back by LendingPool contract, however contract still calculates assets using outdated data.

As result this bad debt will create contract insolvency, which means that contract will not have enough balance to pay last burners.

Impact

Bad debt is not distributed among all lenders

Tools Used

Recommended Mitigation Steps

You should track when position is closed with bad debt and then notify LendingPool contract that borrower will not be able to return part of funds. This should decrease totalDebt amount, which will decrease share price and thus distribute that debt among all lenders.

Assessed type

Error

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L462

Vulnerability details

Proof of Concept

Issue TRST-M-1 from previous audit still exist.

In order to calculate collateral amount getCollateralCreditCurrent_e36 function is used. https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L462 uint tokenValue_e36 = ILendingPool(pools[i]).toAmtCurrent(shares[i]) * tokenPrice_e36;

tokenValue_e36 is usd value of user's shares in the pool. To calculate amount that pool will return for the shares toAmt function is called and this function will use totalAssets() to calculate output amount. totalAssets() is cash + totalDebt.

In case if syncCash is called, then cash is updated with contract balance.

syncCash is called by InitCore.flash function, which means that it's enough for attacker to get a small flash loan then donate tokens to the pool and syncCash will update cahs varible and as result will increase his collateral.

Thus, issue still exists.

Also in similar way poolConfig.supplyCap can be breached, however i don't see issue in this case as it can be breached even non maliciously just with accrued interest adn flash fees.

Impact

It's possible to add more collateral, even when collateralization is paused.

Tools Used

VsCode

Recommended Mitigation Steps

Don't see how to fix this correctly, maybe change flash repayment flow, so flash loaner needs to approve amount to the init core and core will then send tokens with fee to the pool.

Assessed type

Error