Tadle

Summary

The TokenManager contract contains a logical flaw in its token whitelist mechanism that allows non-whitelisted tokens to be used if the _isPointToken parameter is set to true. This vulnerability can lead to unauthorized tokens being deposited and withdrawn, potentially causing financial loss.

Vulnerability Details

https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/TokenManager.sol#L30-L36

https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/TokenManager.sol#L56-L65

The onlyInTokenWhiteList modifier is designed to ensure that only whitelisted tokens can be used in certain functions.

However, the logic is implemented such that the whitelist check is only enforced if the _isPointToken parameter is set to false.

Specifically, the modifier checks if _isPointToken is false and if the token is not whitelisted, it reverts the transaction.

Conversely, if _isPointToken is set to true, the whitelist check is entirely bypassed, allowing any token, whether whitelisted or not, to be used.

This creates a loophole where an attacker or a user can set _isPointToken to true and use non-whitelisted tokens, effectively bypassing the intended security mechanism.

PoC

Detailed step-by-step exploit scenario:

Intial state

• The TokenManager contract is deployed and operational.

• The tokenWhiteListed mapping contains a set of whitelisted tokens.

• The _isPointToken parameter is used to determine if a token is a point token, which bypasses the whitelist check.

Step 1: Attacker Identifies a Non-Whitelisted Token

• The attacker identifies a token that is not included in the tokenWhiteListed mapping.

Step 2: Attacker Prepares to Call tillIn

• The attacker prepares to call the tillIn function of the TokenManager contract.

• They set the _isPointToken parameter to true to bypass the whitelist check.

Step 3: Attacker Calls tillIn with Non-Whitelisted Token

• The attacker calls the tillIn function with the following parameters:

  • _accountAddress: The attacker's address.

  • _tokenAddress: The address of the non-whitelisted token.

  • _amount: The amount of the non-whitelisted token to deposit.

  • _isPointToken: Set to true to bypass the whitelist check.

Step 4: Execution of tillIn Function

• The onlyInTokenWhiteList modifier is invoked, but since _isPointToken is true, the whitelist check is bypassed.

• The function proceeds to execute the deposit logic:

  • If the token is the wrapped native token, it handles the deposit accordingly.

  • Otherwise, it transfers the non-whitelisted token to the capital pool.

Step 5: Non-Whitelisted Token is Deposited

• The non-whitelisted token is successfully deposited into the capital pool.

• The TillIn event is emitted, indicating the deposit of the non-whitelisted token.

Outcome

• The attacker successfully deposits a non-whitelisted token into the capital pool by exploiting the bypass in the onlyInTokenWhiteList modifier.

• The TillIn event is emitted, indicating the deposit of the non-whitelisted token.

Impact

Implications

• Loss of funds:

  • Unauthorized tokens, which not have the same value as whitelisted tokens, can be deposited into the capital pool.

  • This can lead to financial discrepancies and potential loss for the protocol and its users.

• Exploitation by Malicious Actors:

  • Malicious actors can exploit this vulnerability to introduce tokens that could be used to manipulate balances or execute unauthorized transactions.

  • This opens up the system to various forms of manipulation and exploitation.

• Loss of Trust:

  • The overall trust in the protocol could be severely damaged, as users rely on the whitelist to ensure that only vetted and approved tokens are used within the system.

• Potential for Further Exploits:

  • The ability to bypass the whitelist check could be leveraged in combination with other vulnerabilities to create more complex and damaging exploits.

  • For example, attackers could use non-whitelisted tokens to inflate their balances and then withdraw more funds than they are entitled to.

Tools Used

Manual Code Review, foundry

Recommendations

To address the vulnerability in the TokenManager contract, the following changes should be made to ensure that the whitelist check is always performed, regardless of the _isPointToken parameter.

• Remove the conditional check for _isPointToken in the onlyInTokenWhiteList modifier.

• Ensure that the whitelist check is always performed regardless of the _isPointToken parameter.

• Update the tillIn Function:

  • Remove the _isPointToken parameter from the function signature.

    function tillIn(

    address _accountAddress,

    address _tokenAddress,

    uint256 _amount

    )

    external payable

    onlyRelatedContracts(tadleFactory, _msgSender())

    onlyInTokenWhiteList(_tokenAddress)

    {

    // logic

    }

  • Use the updated onlyInTokenWhiteList modifier that always checks the whitelist.

    modifier onlyInTokenWhiteList(address _tokenAddress) {

    if (!tokenWhiteListed[_tokenAddress]) {

    revert TokenIsNotWhiteListed(_tokenAddress);

    }

    _;

    }