Aave DIVA Wrapper

Summary

The _getAccruedYieldPrivate function incorrectly calculates yield by relying on aTokenBalance, which does not automatically reflect accrued interest unless an interaction occurs (e.g., supply, withdraw). Since Aave accrues interest continuously, but aTokenBalance updates only when a state-changing transaction occurs, yield may be underestimated, leading to users losing earned yield over time.

Vulnerable Code

Root Cause

1. Aave’s aToken Balance Does Not Automatically Reflect Accrued Interest

   • Aave accrues interest continuously based on lending pool activity.

   • However, aTokenBalance only updates when a state-changing function is called (e.g., supply, withdraw).

   • If no interactions occur for an extended period, the function underestimates the actual accrued yield.

2. Users Will Lose Earned Yield Until a State-Changing Interaction Occurs

   • If no supply() or withdraw() calls are made, the yield remains unaccounted for.

   • This means users claiming yield may receive less than what they should.

Attack Scenario: Yield Leakage Over Time

Scenario 1: Long-Term Yield Underestimation

1. A user deposits collateral into Aave via the protocol.

2. The protocol earns yield over several months due to Aave’s interest accrual.

3. The user attempts to claim yield using _getAccruedYieldPrivate().

4. Issue: Since no supply() or withdraw() occurred recently, aTokenBalance does not reflect the latest interest accrued.

5. Result: The user receives less yield than they should have earned.

Outcome:

• Users are financially impacted, losing legitimate earnings.

• The protocol appears unreliable, as users will notice discrepancies in expected yield.

Scenario 2: Exploitation via Controlled Yield Refresh

1. An attacker observes that yield is being underreported.

2. They wait until substantial yield has accumulated unclaimed.

3. The attacker triggers a small supply() or withdraw() transaction, forcing Aave to update aTokenBalance.

4. The attacker immediately claims the updated yield, getting more than expected before legitimate users claim.

Outcome:

• Malicious users claim more yield at the expense of others.

• Legitimate users unknowingly lose their rightful yield due to stale balance tracking.

Proof of Concept (PoC)

The following PoC demonstrates how an attacker could refresh aTokenBalance and claim extra yield before regular users.

Step 1: Observe Stale Yield Calculation

Expected output:

Step 2: Force Balance Update by Calling supply()

✅ This forces Aave to update aTokenBalance with accrued interest.

Step 3: Recheck Yield Calculation

Expected output:

Step 4: Immediately Claim Yield

✅ Attacker claims extra yield before regular users update their calculations.

**Impact **

🔴 Severity: Medium-High

• Likelihood: ✅ High (Occurs naturally in the protocol)

• Impact: ✅ High (Users lose legitimate yield)

Financial Consequences

❌ Users lose out on accrued yield due to delayed balance updates.
❌ Attacker can claim extra yield at the expense of regular users.
❌ Protocol appears unreliable, affecting user trust.

Mitigation Strategies

✅ Fix 1: Use Aave’s scaledBalanceOf and Liquidity Index

Instead of using aTokenBalance, use Aave’s liquidity index to factor in accrued interest dynamically.

Updated Code

✅ Accounts for accrued interest in real-time.
✅ Ensures yield is always accurate.

✅ Fix 2: Require Regular Balance Updates

Periodically refresh the Aave aToken balance by triggering supply() or withdraw().

Implementation

✅ Ensures balance remains up-to-date.
✅ Prevents yield underreporting.

✅ Fix 3: User-Triggered Yield Update

Allow users to force a balance update before claiming yield.

Implementation

✅ Ensures users always claim accurate yield.
✅ Prevents front-running yield refresh exploits.