Summary:

The sendProfit function in the MembershipERC1155 contract contains a significant vulnerability that could be exploited by an attacker to manipulate the profit distribution mechanism. This vulnerability stems from the lack of proper checks or restrictions on the amount of profit an attacker can send to the contract, potentially draining the profit pool or redirecting profits to an unintended recipient.

Exact Location:

• The vulnerability exists in the sendProfit function located at line 159 of the contract.

Vulnerability Details:

The function sendProfit(uint256 amount) allows the sender to distribute profits to token holders, but there is a critical flaw: it doesn't properly validate or restrict the amount of currency to be transferred from the sender to the contract. The contract relies on the totalSupply variable to determine the distribution ratio. However, there is no safeguard against manipulating this total supply or abusing the function in specific scenarios.

• Unrestricted Amount Transfer: The contract does not validate the amount argument against the available balance in the contract or the sender's balance, allowing an attacker to send arbitrary amounts of profit. This can lead to several issues, including:

  • Draining the profit pool with inflated amounts.

  • Redirecting excessive profit to the contract creator (if the totalSupply is 0), even in unintended cases.

• Unprotected totalSupply: The totalSupply variable used in the profit distribution formula can be easily manipulated since it is dependent on the minting and burning functions. This allows an attacker to influence the distribution of profits by manipulating token quantities.

• Misuse of Profit Distribution Logic: The calculation of profit shares uses totalSupply and does not account for malicious minting or burning operations that could skew the calculations. This creates an attack vector where attackers can alter the supply to their advantage and disproportionately claim profits.

Impact:

1. Excessive Profit Distribution: If an attacker can manipulate the amount sent through sendProfit, they can cause excessive amounts of profit to be sent to the contract, potentially draining the profit pool or redirecting it to unintended addresses.

2. Profit Pool Drainage: Since there is no check on the amount parameter, malicious actors can flood the system with transactions, draining the entire profit pool by calling the function multiple times with inflated values.

3. Creator Exploitation: In the scenario where the totalSupply is zero (which happens when all tokens are burned), the sendProfit function will send profits to the contract creator directly, which can be abused. An attacker could trigger a situation where the contract considers itself "empty" and inadvertently redirects large amounts of funds to the creator, bypassing intended distribution mechanisms.

4. Disproportionate Profit Claims: If attackers can manipulate the totalSupply or the amount of profit distributed, they can claim a disproportionately large share of the profits by either minting tokens in their own address or manipulating other parameters.

Tools Used:

• Manual Review: Extensive review of contract code, focusing on how profits are distributed and calculated.

• Static Analysis: Tools like MythX or Slither could identify similar issues, but this vulnerability was found due to the interplay between the totalSupply and the profit distribution logic.

• Manual Test Cases: Crafting of test cases that simulate large transfers of profit to check for vulnerabilities.

Recommendations:

1. Amount Validation:

   • Validate the amount parameter to ensure it doesn't exceed the current balance of the contract or the available funds. Consider adding a check to ensure the contract has enough currency to transfer, preventing accidental loss or drain of the funds.

   Example Fix:

   require(amount <= IERC20(currency).balanceOf(address(this)), "Insufficient funds in contract");

2. Limit Profit Distribution to Legitimate Transfers:

   • Introduce restrictions on who can call sendProfit to ensure only authorized addresses (e.g., DAO administrators) can trigger profit distribution. This could be done via an onlyRole() modifier.
     Example Fix:

   modifier onlyAuthorized() {

   require(hasRole(OWP_FACTORY_ROLE, msg.sender), "Unauthorized caller");

   _;

   }

3. Better Tracking of totalSupply:

   • Implement better tracking of totalSupply by ensuring it is not manipulated maliciously during minting or burning. Ensure the total supply reflects actual mintable and burnable tokens that users hold.
     Example Fix:

   totalSupply = totalSupply + amount * 2 ** (6 - tokenId);

   // Ensure this doesn't lead to overcounting or undercounting during token transfers.

4. Check totalSupply Consistency:

   • Ensure totalSupply is updated consistently and can't be easily manipulated. This may involve additional checks when burning or minting tokens.

5. Profit Distribution Formula Safeguard:

   • Instead of directly relying on totalSupply, introduce a separate mechanism to track the actual share of profits each address is entitled to. This can be tracked using a more robust system to store shares or claims.

Proof of Concept for Profit Pool Manipulation

Overview:

An attacker can manipulate the sendProfit function by calling it with arbitrary amounts, either draining the profit pool or redirecting the funds to themselves or the contract creator.

Actors:

• Attacker: The actor that calls sendProfit with an arbitrary amount of funds, manipulating the profit distribution mechanism.

• Victim: The other token holders and participants who are supposed to share the profit, but instead, their profit distribution is skewed or drained.

• Protocol: The MembershipERC1155 token protocol, which distributes profits among token holders.

Working Test Case (if applicable):

Conclusion:

This vulnerability has significant potential for exploitation, as it allows an attacker to manipulate the profit distribution mechanism and either drain the profit pool or redirect it to unintended recipients. It poses a high risk to the integrity of the contract and can lead to substantial financial loss if not fixed. The recommended fixes should be applied urgently to mitigate the potential damage caused by this flaw.