Beedle - Oracle free perpetual lending

repay()

Scenario:

• Pool configuration: Debt represented by Scammers token (STKN), Collateral could be any valuable token like WBTC.

• Malicious Borrower (MB): This is just a disguise. In reality, it's another address owned by the pool's lender.

• There are legitimate users whom the scammers have persuaded to use their STKN.

Steps:

1️⃣. MB borrows a certain amount of STKN, providing 300 WBTC as collateral.

2️⃣. A legitimate user borrows STKN, depositing 700 WBTC.

3️⃣. The malicious borrower (MB) then calls repay(). However, the STKN contract contains reentrant code which triggers repay() again, causing it to execute twice.

Assuming MB uses the same loanId for both calls to repay():

• The first call acts as expected, returning 300 WBTC to MB.

• The second call, however, extracts another 300 WBTC from the pool. This is because the pool, at that moment, has a total of 1000 WBTC and believes it has sufficient balance to return 300 WBTC. This is despite the fact that those 1000 WBTC were deposited by different users.

Visualization of the second call to repay() with inline explanations. Read first the comment marked with 1️⃣❗❗, then go to the top of the function again and read the comments in execution order:

🚧 Note ⚠️: If you are not familiar on how a reentrancy attacker contract looks like here is an example: Solidity by Example, Reentrancy

Now the pool has 400 WBTC left and if the valid user tries to repay its debt there is no way the pool can give him back the 700 WBTC.

🚧 Note ⚠️: More sophisticated scams can employ genuine, value-bearing tokens as a decoy. They might lure non-technical users through a PROXY contract. This proxy seemingly manages the users' real tokens by redirecting all lending activities to the legitimate ERC20 token contract. However, before this redirection occurs, the proxy might sometimes execute malicious operations. This tactic creates an illusion, leading users to believe that their genuine tokens are being managed correctly. In reality, they're being manipulated through the PROXY contract.

borrow() and setPool()

The problem with these 2 functions is essentially the same. They can be used to fill up the contract's storage with fake values effectively making it more expensive to operate with.

In setPool() users can create as much pools as they want and in borrow() users can push as much loans as they want to the loans array. Here reentrancy only helps them with creating more fake objects in storage with less transactions.

📘 Notice ℹ️: I've covered this storage exploit more detaildly and proposed solutions in other of my findings.

🚧 Note ⚠️ There might likely be more possible exploits with the reentrancies of these 2 functions.

buyLoan()

Emits duplicate events, extra fees are paid, pools' debt can be doubled... Notice, in this case, reentrancy can be avoided just by simply applying the Checks-Effects-Interactions pattern.

zapBuyLoan()

As zapBuyLoan() calls buyLoan() and setPool(), it can be used to execute the exploits mentioned in those functions.

refinance() , seizeLoan() and giveLoan()

Due to timing reasons, I cannot provide detailed examples for these other 3 functions, but they manage funds and suffer from reentrancy, given the explained errors along the report they are highly likely to be a source for scammed funds or directly, stolen funds.

addToPool() and removeFromPool()

I couldn't find any exploit using these functions but reentrancy is posible on them.