Aave DIVA Wrapper

Summary

The contract AaveDIVAWrapperCore.sol uses the mapping _collateralTokenToWToken to verify whether collateral tokens are registered. However, it assumes that any unregistered collateral token should revert, but this doesn't handle edge cases or failed operations well.

Vulnerability Details

In functions like _claimYield and _approveCollateralTokenForAave, the contract checks whether a collateral token is registered by looking up in the _collateralTokenToWToken mapping. If the mapping doesn't contain the collateral token, the function reverts with a CollateralTokenNotRegistered error. While this is a safeguard, it may not provide sufficient feedback to the caller, and it’s not clear whether this behavior handles all edge cases properly.

Impact

The lack of proper handling for unregistered collateral tokens could lead to failed operations, causing users to lose funds or experience interruptions. Furthermore, it doesn’t offer enough clarity on why a transaction failed, potentially leading to confusion.

Proof of Concept for Insecure Handling of Collateral Token Registration

Overview:

The vulnerability arises from improper validation during the registration of collateral tokens, allowing an attacker to register malicious or unauthorized tokens. This weakens the protocol’s security, as malicious tokens could be added, leading to potential loss or manipulation of funds.

Actors:

• Attacker: A user attempting to register an unauthorized or malicious token as collateral.

• Victim: The users relying on the protocol’s collateral for securing loans or engaging in financial transactions.

• Protocol: The system or contract that allows tokens to be registered as collateral but lacks proper checks to ensure token validity.

Working Test Case:

Line-by-line Comments:

• mapping(address => bool) public registeredTokens;: This line stores the registered collateral tokens by their address.

• function registerCollateral(address token) external {: The function that allows users to register tokens as collateral.

• registeredTokens[token] = true;: The vulnerability—this line registers the provided token address without validating if it's a real ERC20 token or authorized for collateral use. An attacker could register a malicious token, which might not be safe for use.

Exploit Scenario:

Initial State:

• The protocol allows users to register tokens as collateral.

• No validation is done to ensure the token is legitimate or safe.

• An attacker has the contract's interface and can interact with it.

Step 1:

• The attacker identifies the function to register tokens as collateral (registerCollateral).

• The attacker prepares a malicious token contract (e.g., a token that can transfer funds on behalf of others when interacted with).

Step 2:

• The attacker calls the registerCollateral function, passing the address of the malicious token.

• Since the contract doesn't validate the token, the malicious token is successfully registered.

Step 3:

• The attacker proceeds to leverage this registered token as collateral in the system, initiating potentially malicious actions, such as transferring funds or manipulating the state of the protocol.

Outcome:

• The malicious token has been successfully registered and can be used as collateral.

• The protocol and its users are now exposed to risks like the attacker draining funds or exploiting the token.

Implications:

• Financial Loss: Malicious tokens can be used to manipulate the protocol and cause significant financial loss.

• Reputation Damage: If the vulnerability is exploited, the reputation of the protocol would suffer.

• Smart Contract Exploitation: Attackers can exploit the system to carry out further malicious activities, depending on the functionality of the collateral-related logic.

  Mitigation:

  • Token Validation: Introduce checks to ensure the registered token is a valid ERC20 token by interacting with the ERC20 interface. Example check:

  require(ERC20(token).totalSupply() > 0, "Invalid token");

  • Access Control: Restrict the ability to register tokens to an authorized user or role (e.g., admin).

  require(msg.sender == admin, "Not authorized");

• Whitelisting: Use a whitelist of approved tokens instead of allowing any token to be registered.

  mapping(address => bool) public approvedTokens; require(approvedTokens[token], "Token not approved");

• Reentrancy Checks: Ensure no function that can be exploited by malicious token behavior allows reentrancy.

Tools Used

Manual code review

Recommendations

1. Provide better feedback to users when an unregistered collateral token is detected, and consider logging such events for transparency.

2. Ensure that any token registration process has strong safeguards and clarity to avoid misconfiguration.