Aave DIVA Wrapper

Summary

The approveCollateralTokenForAave function on line 246 in the contract IAaveDIVAWrapper.sol increases the allowance to Aave for a collateral token but does not ensure the allowance is properly reset to 0 before increasing it. This could cause issues with tokens like USDT, which require zeroing out the approval before increasing it.

Vulnerability Details

Some ERC20 tokens, such as USDT, require a zero approval before an increase. Not doing this could lead to situations where the approval becomes stuck or exceeds the intended limits.

Impact

Users could inadvertently approve more tokens than intended, or the operation could fail.

Proof of Concept (PoC) for Collateral Token Approval Not Reverted in approveCollateralTokenForAave

Overview:

This PoC demonstrates the potential issue where the approveCollateralTokenForAave function increases the approval allowance for a collateral token without resetting the allowance to 0 before increasing it. This can cause issues, especially with ERC20 tokens (e.g., USDT) that require a zero approval before increasing the allowance.

Actors:

• Attacker: A malicious user interacting with the contract.

• Victim: The user whose tokens are being approved for Aave.

• Protocol: The IAaveDIVAWrapper contract, which interacts with Aave to approve collateral tokens.

Test Case Setup:

1. Deploy a token contract (e.g., USDT or any ERC20 token).

2. Deploy the IAaveDIVAWrapper contract with a call to the approveCollateralTokenForAave function.

3. The attacker will exploit the lack of resetting the approval before increasing it by attempting to approve more tokens than necessary, potentially causing unexpected behavior or token approval overflows.

Test Case Code:

Step-by-Step Exploit Scenario:

1. Initial Setup:

   • Deploy a mock ERC20 token (e.g., USDT) and the IAaveDIVAWrapper contract.

   • Transfer tokens to both the attacker and the victim.

2. Step 1: Initial Approval:

   • The attacker calls the approve function on the token contract to approve the IAaveDIVAWrapper contract to spend 100 tokens on their behalf.

3. Step 2: Second Approval Without Resetting:

   • The attacker calls the approve function again, this time for 200 tokens, but does not reset the allowance first.

   • This increases the allowance without checking if the previous allowance is set to zero, leading to unexpected token approvals.

4. Step 3: Attack Execution:

   • The attacker then interacts with the approveCollateralTokenForAave function in the IAaveDIVAWrapper contract, causing another increase in the token allowance for Aave.

   • The attacker can control the approval flow, potentially causing an excessive amount of tokens to be approved and exploited.

5. Outcome:

   • The allowance will show that it was increased multiple times without resetting it, demonstrating that the contract lacks a safety mechanism.

   • If the tokens are then transferred, the attacker can withdraw more than intended or cause other unexpected issues.

Expected Outcome & Implications:

• Outcome: The allowance of tokens for Aave would be set multiple times without resetting, allowing the attacker to potentially manipulate the flow.

• Implications:

  • If the contract does not manage token allowances correctly, it could lead to situations where too many tokens are approved for withdrawal, leading to a potential drain or manipulation of funds.

  • In case of using tokens like USDT, where it is required to set the approval to zero before increasing, failing to reset the approval could cause errors or unintended behavior in some ERC20 tokens.

Tools Used

Manual code review

Recommendations

Recommendations & Fixes:

• Fix:

  • Use safeIncreaseAllowance from OpenZeppelin, which ensures proper handling of allowances, or manually reset the allowance to 0 before increasing it:

    token.approve(spender, 0); // Reset approval first

    token.approve(spender, newAmount); // Increase the approval

    ​

  • This ensures the contract behaves correctly for tokens that require resetting the allowance to prevent unexpected behavior.