HardhatDeFi
15,000 USDC
View results
Submission Details
Severity: high
Invalid

Double Yield Claims Without Reentrancy in `AaveDIVAWrapper`

Summary

The AaveDIVAWrapper contract allows unauthorized repeated yield claims due to insufficient state tracking. This logical vulnerability does not rely on reentrancy and enables attackers to claim yields multiple times using the same wToken balance. This results in unauthorized withdrawals, depleted reserves, and reduced protocol trust.


Detailed Analysis

Root Cause

The root issue lies in the yield claiming functions (redeemWToken and redeemPositionToken) which:

  1. Depend solely on the current wToken balance to calculate yield without considering previously claimed amounts.

  2. Lack a state-tracking mechanism (e.g., mappings) to record yields already claimed by users.

Key Code Excerpt

The redeemWToken function in the contract:

function redeemWToken(address _wToken, uint256 _wTokenAmount, address _recipient) external override returns (uint256) {
uint256 yield = _calculateYield(_wToken, _wTokenAmount);
require(yield > 0, "No yield to claim");
// Transfers yield without tracking previous claims
IERC20(_wToken).transfer(_recipient, yield);
return yield;
}
  • The absence of state updates after yield calculation allows users to repeat the process indefinitely.


Attack Scenario

Objective: Repeatedly exploit the lack of state tracking to drain yield reserves.

  1. Setup:

    • The attacker deposits a significant amount of collateral into the protocol, receiving wTokens.

  2. Initial Yield Accrual:

    • Over time, the attacker accrues yields based on their collateral holdings.

  3. First Yield Claim:

    • The attacker calls redeemWToken to claim their yield. The function calculates the yield using the wToken balance and transfers the amount.

  4. Exploitation:

    • The attacker calls redeemWToken again using the same wToken balance. Since no state tracks the claimed amount, the yield is recalculated and transferred again.

    • This process can be repeated indefinitely to drain the protocol’s reserves.


Impact

Severity: High

  1. Unauthorized Withdrawals:

    • Attackers can repeatedly withdraw funds beyond their rightful entitlement.

  2. Depleted Reserves:

    • The protocol’s yield reserves are drained, preventing legitimate users from claiming their rightful yields.

  3. Reputation Damage:

    • Users lose trust in the protocol due to financial discrepancies and reduced reliability.


Recommendations

1. Implement State Tracking for Claimed Yields

Introduce a mapping to track claimed amounts:

mapping(address => uint256) private _claimedYields;
function redeemWToken(address _wToken, uint256 _wTokenAmount, address _recipient) external override returns (uint256) {
uint256 yield = _calculateYield(_wToken, _wTokenAmount);
require(yield > 0, "No yield to claim");
require(_claimedYields[msg.sender] + yield <= _maxYield[msg.sender], "Yield already fully claimed");
_claimedYields[msg.sender] += yield;
IERC20(_wToken).transfer(_recipient, yield);
return yield;
}

2. Enforce Yield Claim Caps

Establish a maximum allowable yield per user, dynamically calculated based on their wToken balance or predefined limits.

Updates

Lead Judging Commences

bube Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.