Core Contracts

Summary

The veRAACToken contract is designed as a non-transferable ERC20 token representing governance voting power. To enforce non-transferability, the contract overrides the standard ERC20 transfer functions—transfer and transferFrom—and implements an internal _update function that reverts any transfer attempts. However, the approve function remains unmodified, allowing token holders to set allowances despite the tokens being non-transferable.

This discrepancy creates a serious phishing vulnerability. A malicious token holder, "Devil," can exploit the open approval mechanism to trick unsuspecting users, such as "Alice," into believing they can control or utilize Devil’s veRAACTokens. For example, Devil might offer to approve his veRAACTokens to Alice, promising that she can leverage that approval to gain governance influence or voting power. In return, Devil could demand compensation in the form of other tokens or assets. When Alice later attempts to spend or transfer the approved tokens, the transaction will fail due to the enforced transfer restrictions, leaving her defrauded. This attack not only undermines governance integrity but also disrupts the voting process and damages user trust in the protocol.

Vulnerability Details

Incomplete Override of ERC20 Functions

The veRAACToken contract effectively disables token transfers by overriding the standard ERC20 functions. The transfer and transferFrom functions are implemented as follows:

The critical internal function _update is then overridden to prevent any token transfer between non-zero addresses:

This design ensures that veRAACTokens remain non-transferable and only exist for governance purposes.

Unrestricted Approval Mechanism

Despite the restrictions on transfers, the approve function is not overridden. This leaves the standard ERC20 approval functionality intact, allowing any token holder to grant an allowance to another address. While no one can later transfer tokens (since transfer operations are prohibited), this creates a dangerous scenario:

• Phishing Opportunity: A malicious veRAACToken holder ("Devil") can offer to approve his tokens to a target user ("Alice"), falsely claiming that Alice can exercise control over those tokens or use them to participate in governance votes.

• Deceptive Compensation: Devil may ask Alice for compensation in other tokens or assets in exchange for granting her the approval. However, when Alice tries to spend or transfer the approved tokens, her transactions will revert because the overridden _update function prevents any actual transfer.

• Governance Impact: Since veRAACTokens confer voting power, such phishing attacks could disrupt the governance process.

Proof of Concept

To demonstrate this vulnerability, the following Proof of Concept (PoC) is provided. The PoC is written using the Foundry tool.

1. Step 1: Create a Foundry project and place all the contracts in the src directory.

2. Step 2: Create a test directory and a mocks folder within the src directory (or use an existing mocks folder).

3. Step 3: Create all necessary mock contracts, if required.

4. Step 4: Create a test file (with any name) in the test directory.

5. Step 5: Add the following test PoC in the test file, after the setUp function.

6. Step 6: To run the test, execute the following commands in your terminal:

7. Step 7: Review the output. The expected output should indicate that malicious token holders can phish others and make them victim.

As demonstrated, the test confirms that the malicious token holder can Phish others like Alice and afterwards victims like alice will face a Denial of Service (DoS) due to non-transferrability of veRAAC Tokens.

Explanation

1. Setup:

   • The veRAACToken contract is deployed, and Devil is assigned a balance of veRAACTokens.

2. Approval:

   • Devil calls approve to allow Alice an allowance of his tokens.

3. Phishing Attempt:

   • Alice, thinking she can transfer or use these tokens, calls transferFrom to move the tokens. However, due to the overridden _update function, the transfer reverts, demonstrating the flaw.

4. Outcome:

   • The PoC confirms that although approval is granted, any subsequent transfer attempt fails, effectively enabling Devil to scam Alice.

Impact

• Governance Manipulation:
  Malicious actors can record false approvals to mislead victims, potentially manipulating voting power in governance decisions.

• Voter Denial of Service:
  Legitimate users may be prevented from participating in governance if their addresses are misrepresented as having already cast votes or as being controlled by malicious parties.

• Erosion of User Trust:
  The inconsistency between the non-transferable nature of the tokens and the functioning approval mechanism can lead to confusion and loss of confidence in the protocol.

• Phishing Risk:
  Malicious token holders may use the approval feature to lure victims into fraudulent schemes, thereby causing financial loss and reputational damage to the protocol.

Tools Used

• Manual Review

• Foundry

• Console Log (Foundry)

Recommendations

• Override or Restrict the approve Function:

  • Modify the approve function to either revert or restrict its usage in veRAACToken, given that transfers are prohibited. This can be achieved by overriding approve in the same manner as transfer and transferFrom, ensuring consistency in access control.

  • For example:

    function approve(address spender, uint256 amount) public virtual override returns (bool) {

    revert("Approval is disabled for veRAACTokens");

    }