Core Contracts

Summary

The vulnerability resides in the DebtToken's transferability (Lines not explicitly restricted in DebtToken.sol), allowing attackers to separate debt ownership from protocol accounting. By transferring DebtTokens, malicious actors can manipulate debt repayments, leading to protocol insolvency and corrupted user debt tracking.

Vulnerability Details

Technical Analysis

The LendingPool contract tracks user debt via the scaledDebtBalance variable but calculates repayable amounts using the ERC20 balanceOf method of the DebtToken. If the DebtToken is transferable (default ERC20 behavior), attackers can:

1. Transfer DebtTokens to other addresses.

2. Exploit the fragmented debt ownership to repay inflated balances.

3. Cause underflows in scaledDebtBalance or drain reserves via over-repayment.

Affected Code Snippets:

1. DebtToken Transfer Function (assuming standard ERC20):

   function transfer(address to, uint256 amount) public returns (bool) {

   // No restrictions on transfers

   _transfer(msg.sender, to, amount);

   return true;

   }

2. Repayment Logic in LendingPool (Lines 312-335):

   function _repay(uint256 amount, address onBehalfOf) internal {

   uint256 userDebt = IDebtToken(...).balanceOf(onBehalfOf); // Uses ERC20 balance

   // ...

   IDebtToken(...).burn(onBehalfOf, amount, reserve.usageIndex); // Burns transferred tokens

   user.scaledDebtBalance -= amountBurned; // Risk of underflow

   }

Impact

1. Protocol Insolvency: Attackers repay debts using transferred tokens, draining reserves without collateral.

2. Debt Tracking Corruption: Underflows in scaledDebtBalance disrupt interest calculations.

3. Free Debt Arbitrage: Malicious users "sell" debt tokens to unwitting parties, profiting from protocol flaws.

Tools Used

1. Manual Code Review: Identified reliance on transferable DebtToken balances.

2. Hardhat: Simulated token transfers and repayment inconsistencies.

3. Slither: Detected unsafe ERC20 balance usage in critical logic.

Proof of Concept (PoC)

Overview:

An attacker transfers DebtTokens to a victim, tricking the protocol into accepting over-repayments that corrupt debt tracking.

Actors:

• Attacker: Transfers debt tokens to exploit repayment logic.

• Victim: Repays inflated debt using transferred tokens.

• Protocol: Incorrectly reduces debt balances, enabling reserve theft.

Working Test Case:

Recommendations

1. Disable DebtToken Transfers:
   Override ERC20 transfer functions in DebtToken:

   function transfer(address, uint256) public override returns (bool) {

   revert("DebtToken: Transfers disabled");

   }

2. Use Internal Debt Tracking:
   Replace balanceOf with the stored scaledDebtBalance in repayment logic:

   uint256 userDebt = user.scaledDebtBalance.rayMul(reserve.usageIndex);

3. Validate Debt Ownership:
   Add a modifier to ensure only the debt owner can repay:

   modifier onlyDebtOwner(address user) {

   require(msg.sender == user, "Unauthorized repayment");

   _;

   }

Conclusion

Transferable DebtTokens decouple ERC20 balances from protocol debt tracking, enabling reserve drainage and state corruption. Immediate mitigation requires disabling transfers and revising repayment logic to use internal debt records.