Core Contracts

Summary

The Treasury contract does not restrict which ERC20 tokens it accepts. An attacker can deploy a malicious ERC20 token that appears legitimate and deposit it into the Treasury. Later, when the Treasury attempts to withdraw funds, the malicious token’s custom transfer function executes code that sets an approval for a legitimate token held by the Treasury granting the attacker permission to drain those funds. This vulnerability could enable an attacker to steal Treasury tokens even if the withdrawal function is called by an authorized manager.

Vulnerability Details

• No Token Whitelist:
  The Treasury contract accepts deposits from any token address without validating whether it is an approved or trusted token. This opens the door for an attacker to introduce a malicious token.

• Malicious Token Behavior:
  The attacker creates an ERC20 token with a custom transfer function that, when invoked, performs an extra operation. For example, during a withdrawal, the Treasury calls:

  IERC20(token).transfer(recipient, amount);

  If token is the malicious ERC20, its transfer function can be crafted to include a call to approve. This approval can authorize a malicious address to spend a legitimate token held by the Treasury. For example:

  function transfer(address recipient, uint256 amount) external returns (bool) {

  // Normal transfer logic here...

  // Malicious behavior: approve attacker to spend a legitimate token from the Treasury.

  IERC20(legitTokenAddress).approve(attackerAddress, type(uint256).max);

  return true;

  }

  Because the Treasury does not whitelist tokens, the malicious token is accepted during deposit and later triggers this behavior during a withdrawal.

• Exploitation Flow:

  1. Deployment and Deposit:
     The attacker deploys a malicious ERC20 token that implements a custom transfer function as described. The attacker deposits this token into the Treasury, inflating the internal balance for that token.

  2. Withdrawal Trigger:
     At a later time, an authorized manager or even an automated process triggers a withdrawal that involves the malicious token.

  3. Custom Transfer Execution:
     During the withdrawal, the Treasury calls the token’s transfer(recipient, amount) function. Instead of merely transferring tokens, the malicious token’s code executes an additional approve call on a legitimate token (which the Treasury holds) and grants unlimited allowance to the attacker.

  4. Draining Funds:
     The attacker, now approved, can call transferFrom on the legitimate token to drain the Treasury’s balance for that token.

Impact

• Unauthorized Token Approvals:
  The Treasury ends up approving the attacker to spend its legitimate tokens, bypassing its internal access controls.

• Theft of Treasury Assets:
  Once the approval is in place, the attacker can transfer the approved tokens out of the Treasury, resulting in a direct loss of funds.

Tools Used

Manual Review

Recommendations

Implement Token Whitelisting:
Restrict the Treasury to accept only pre-approved ERC20 tokens. Maintain a list of trusted token addresses and reject deposits from any token not on that list.