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

Lack of Validation on Asset Input for `supply` and `withdraw`

futhmah456

Summary

The supply and withdraw functions in IAave.sol contract do not perform sufficient validation on the asset parameter. An attacker could potentially send an unsupported asset type, leading to failures or unexpected behavior.

Vulnerability Details

  • The functions accept an asset parameter (address), which is not validated to ensure it is a valid, supported token within the protocol.

  • If an unsupported asset is supplied, it could result in loss of funds or other unintended effects.

Impact

  • An attacker could send an unsupported asset (e.g., a non-ERC20 token or malicious contract) to these functions, breaking the protocol's behavior.

  • This could cause funds to be locked, loss of liquidity, or prevent proper interaction with the protocol.

Proof of Concept for Finding 2: Lack of Validation on Asset Input for supply and withdraw

Overview:

The supply and withdraw functions do not validate the asset parameter (address) to ensure it is a valid, supported ERC20 token. This could lead to issues where unsupported or malicious tokens are interacted with, causing unexpected behavior or potential loss of funds.

Actors:

  • Attacker: The entity providing an unsupported asset (e.g., a non-ERC20 token or malicious token) to the supply or withdraw functions.

  • Victim: The protocol’s liquidity reserves.

  • Protocol: The Aave contract system that interacts with ERC20 tokens for asset supply and withdrawal.

Working Test Case:

// Solidity code demonstrating the lack of validation on asset input
​
// Step 1: Attacker deploys a malicious token contract (non-ERC20 or malicious ERC20)
contract MaliciousToken {
function transfer(address recipient, uint256 amount) public returns (bool) {
// Potentially faulty logic or malicious behavior
return false; // Simulating failure in the token transfer
}
// Other ERC20 functions could be missing or behave unexpectedly
}
​
// Step 2: Attacker deploys the malicious token contract and supplies it to the Aave contract
MaliciousToken maliciousToken = new MaliciousToken();
​
// Attacker attempts to supply malicious token to Aave
aave.supply(address(maliciousToken), 1000, attacker.address, 0);
​
// Explanation:
// 1. The attacker deploys a malicious token that does not conform to ERC20 standards or has faulty logic (e.g., the transfer function fails).
// 2. The attacker attempts to supply this token to Aave using the `supply` function.
​
// Step 3: Attacker attempts to withdraw using the same malicious token
aave.withdraw(address(maliciousToken), 1000, attacker.address);
​
// Explanation:
// 1. The attacker now tries to withdraw the same unsupported or malicious token using the `withdraw` function.
// 2. This will cause issues since the token might not transfer correctly or could cause unexpected behavior due to missing or faulty functions.
​

Outcome & Implications:

  • Outcome: The transaction will likely fail or behave unexpectedly. The malicious token may not conform to the ERC20 standard, leading to failed transfers or loss of liquidity. In the worst case, the protocol could be exposed to malicious contracts that cause further issues in the system.

  • Implications: If the protocol does not validate tokens properly, it opens up the risk of interacting with unsupported or malicious tokens, which could drain funds or cause other unintended consequences, such as locking up liquidity or interfering with normal operations.

Tools Used

Manual code review

Recommendations

  • Token Validation: Introduce checks in the supply and withdraw functions to validate that the asset being supplied or withdrawn is an actual ERC20 token. This could be done by checking if the token implements the transfer function or using try/catch to handle invalid tokens.

  • ERC20 Interface Check: You can use IERC20 interface functions to validate if the provided token conforms to the expected interface before proceeding with the operation. For example, checking that the transfer and transferFrom functions exist and behave correctly.

  • Example Validation Code:

    interface IERC20 {
    function transfer(address recipient, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
    // Other ERC20 functions...
    }
    ​
    function validateToken(address token) internal view returns (bool) {
    return (IERC20(token).transfer(address(this), 1)); // Test if the token can transfer
    }
    ​
    function supply(address asset, uint256 amount, address onBehalfOf, uint16 referralCode) external {
    require(validateToken(asset), "Invalid ERC20 token");
    // Proceed with the rest of the function logic
    }
    ​
    function withdraw(address asset, uint256 amount, address to) external returns (uint256) {
    require(validateToken(asset), "Invalid ERC20 token");
    // Proceed with the rest of the function logic
    }
    ​
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.