Anyone can sandwich a partial repayment of the borrower to steal the surplus fee

[c4-bot-8]

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/governance/ProfitManager.sol#L292

Vulnerability details

Explanation

When the borrower calls the partialRepay function, it triggers a call to the ProfitManager contract, specifically to the notifyPnL function. This function manages the profits from the repayment, and part of the profits are added to the surplus.

As there is no restrictions to staking and unstaking, a bad actor can mint a lot of credit tokens and stake them into the surplus contract right before the partialRepay is called by the borrower, and unstake and burn the tokens right after, which makes it possible to extract value without really investing on the protocol, stealing from the lenders.

This also makes it possible for the borrower to end up paying a little less in fees, as he can do the same with a flash loan, minting credit tokens, staking them, calling the partialRepay function, unstaking and then burning the tokens, and repaying the flash loan if it seems profitable.

Impact

As there is a potential for a sandwich attack that can drain the fees from the surplus, it can lead to no one being incentivized to provide liquidity for the surplus.

Proof of Concept

Borrower tries to repay a part of the loan

Borrower sends the partialRepay function call to a public mempool

Order:
1- borrower repayment

Bad actor snipes it, sets the sandwich attack

Bad actor mints CREDIT tokens in exchange of his own liquidity and stakes them before the borrower  makes the call

Order: 
1- bad actor mint + stake
2- borrower repayment

Bad actor makes a second transaction go right after the borrower repayment

Bad actor unstakes the CREDIT tokens then burns them for his own liquidity + rewards

Order: 
1- bad actor mint + stake
2- borrower repayment
3- bad actor unstake + burn

This is due to the partialRepay function calling the notifyPnL function from the ProfitManager contract, which handles the profit made in the same tx

Tools Used

VSCode

Recommended Mitigation Steps

The rewards could be queued to be distributed and need to be executed on a future block to prevent this kind of attack.

Assessed type

Context

[c4-pre-sort]

0xSorryNotSorry marked the issue as sufficient quality report

[c4-pre-sort]

0xSorryNotSorry marked the issue as duplicate of #994

[c4-judge]

Trumpero marked the issue as satisfactory