malicious user can exploit invite system

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0x2991846bf11bf6f3ff583582a62b8f990433178e5528c57ff6aeaed44654d285 Severity: medium

Description: Description\ Malicious user can invite more people than expected within the same time period. After the invitationOnlyTime, new users need to be invited by already registered users. There is a cost for the inviter and a bonus for the new user.

    uint256 private constant WELCOME_BONUS = 48 * EXA;
    uint256 private constant INVITATION_COST = 2 * WELCOME_BONUS;

According to tests, user needs to wait around 4 days to call the personalMint() function and mint > 96 tokens to invite new user to the protocol. If user wants to invite 3 people, he need to wait around 12 days to mint the invitation cost for 3 people to be able to invite them.

The issue is that malicious user can take unfair advantage and invite 4 people and gain some extra tokens within the same 12-day period.

Consider these 2 scenarios:

Normal Conditions

• Alice wants to invite 3 people.
• Alice waits for 12 days after registration.
• Alice calls personalMint() and mints around 290 tokens.
• Now with these tokens, Alice can invite 3 people.
• Invitation cost of 3 people: 96 * 3 = 288.
• Alice's balance after inviting 3 people: 290 - 288 = 2 tokens.

Exploit

• Alice waits around 4 days after registration.
• Alice calls personalMint() and mints around 96 tokens.
• Alice creates another wallet (Alice2) and invites herself.
• Now Alice's balance is zero because she invited Alice2, and Alice2's balance is 48 because of the bonus.
• After around 8 days, Alice's balance will be around 192 tokens (96 * 2 = 192), and Alice2's balance will be around 240 because of the extra 48 token bonus (192 + 48 = 240).
• Now Alice can invite 2 people using the first wallet: 192 - 96 2 = 0 tokens, then invite another 2 people using the second Alice2 wallet: 240 - 96 2 = 48 tokens.
• Alice ends up with 4 invitations and an extra 48 tokens.

As we can see, this is an unfair advantage because in the first scenario, normal user will be able to invite just 3 users after 12 days, but in the second scenario, user can invite 4 people after 12 days (same duration).

POC\ This test shows that under normal conditions, users who wait for 12 days can only invite 3 users.

• Add this function to test/hub/V1MintStatusUpdate.t.sol

• Run with forge t --mt test_normal_condition -vvv

  function test_normal_condition() public{
      address Alice = makeAddr("Alice");
      address user1 = makeAddr("user1");
      address user2 = makeAddr("user2");
      address user3 = makeAddr("user3");
      address user4 = makeAddr("user4");
  
      ITokenV1 tokenAlice = signupInV1(Alice);
  
      mintV1Tokens(tokenAlice);
  
      vm.startPrank(Alice);
      tokenAlice.stop();
      assertTrue(tokenAlice.stopped(), "Token not stopped");
      vm.warp(1670630401 + 10);
      mockHub.registerHuman(address(0), bytes32(0));
      assertTrue(mockHub.isHuman(Alice), "Alice not registered");
      vm.stopPrank();
  
      skipTime(4 days + 1 hours);
      skipTime(4 days + 1 hours);
      skipTime(4 days + 1 hours);
  
      vm.prank(Alice);
      mockHub.personalMint();
      uint aliceTokenBalanceAfterMint = mockHub.balanceOf(Alice, mockHub.toTokenId(Alice));
      console.log("alice balance after 12 days: ", aliceTokenBalanceAfterMint);
      // 96.9 * 3 = 290 token
  
      vm.prank(Alice);
      mockHub.trust(user1, type(uint96).max);
      vm.prank(user1);
      mockHub.registerHuman(Alice, bytes32(0));
      assertTrue(mockHub.isHuman(user1), "Bob not registered");
  
      vm.prank(Alice);
      mockHub.trust(user2, type(uint96).max);
  
      vm.prank(user2);
      mockHub.registerHuman(Alice, bytes32(0));
      assertTrue(mockHub.isHuman(user2), "Bob not registered");
  
      vm.prank(Alice);
      mockHub.trust(user3, type(uint96).max);
  
      vm.prank(user3);
      mockHub.registerHuman(Alice, bytes32(0));
      assertTrue(mockHub.isHuman(user3), "Bob not registered");
  
      vm.prank(Alice);
      mockHub.trust(user4, type(uint96).max);
  
      vm.startPrank(user4);
      vm.expectRevert(); //will revert because there is no token to cover user 4 INVITATION_COST
      mockHub.registerHuman(Alice, bytes32(0));
      vm.stopPrank();
  
      uint aliceTokenBalanceAfterRegisters = mockHub.balanceOf(Alice, mockHub.toTokenId(Alice));
      console.log("alice balance after 3 user registeration: ", aliceTokenBalanceAfterRegisters);
      // 290 - 96 * 3 = 2 token
      uint INVITATION_COST = 96e18;
  
      // there is no token to cover INVITATION_COST to register another user
      assert(aliceTokenBalanceAfterRegisters < INVITATION_COST);
  }

Now, the test below shows that user who exploits the invite system can invite 4 people plus have 47 extra tokens in the same period above (12 days).

• Add this function to test/hub/V1MintStatusUpdate.t.sol
• Run with forge t --mt test_exploit -vvv

function test_exploit() public{
         address Alice = makeAddr("Alice");
         address Alice2 = makeAddr("Alice2");

        ITokenV1 tokenAlice = signupInV1(Alice);

        mintV1Tokens(tokenAlice);

        vm.startPrank(Alice);
        tokenAlice.stop();
        assertTrue(tokenAlice.stopped(), "Token not stopped");
        vm.warp(1670630401 + 10);
        mockHub.registerHuman(address(0), bytes32(0));
        assertTrue(mockHub.isHuman(Alice), "Alice not registered");
        vm.stopPrank();

        skipTime(4 days + 1 hours);

        vm.prank(Alice);
        mockHub.personalMint();

        vm.prank(Alice);
        mockHub.trust(Alice2, type(uint96).max);
        vm.prank(Alice2);
        mockHub.registerHuman(Alice, bytes32(0));
        assertTrue(mockHub.isHuman(Alice2), "Bob not registered");

        skipTime(8 days);
        vm.prank(Alice);
        mockHub.personalMint();

        vm.prank(Alice2);
        mockHub.personalMint();

        uint aliceBalance = mockHub.balanceOf(Alice, mockHub.toTokenId(Alice));
        uint alice2Balance = mockHub.balanceOf(Alice2, mockHub.toTokenId(Alice2));

        console.log("alice balance", aliceBalance);
        console.log("alice2 balance", alice2Balance);

        // checking balance for inviting 4 people
        uint INVITATION_COST = 96e18;
        assert(aliceBalance - INVITATION_COST * 2 > 0);
        assert(alice2Balance - INVITATION_COST * 2 > 0);

        // checking for extra 47 tokens
        assert(alice2Balance - INVITATION_COST * 2 > 47e18);

    }

Recommendation\ Burning user tokens for invitation costs is easily escapable because user can create multiple accounts by inviting themselves, and these accounts can now be used to invite more people.

One solution is to require users to pay the invitation cost using the native token.

[benjaminbollen]

Thank you for your report on the potential exploitation of the invite system. After review, we've determined this is not an issue.

The scenario you've described, where a user creates additional accounts to gain more invitations, is an understood aspect of our permissionless design. The invitation cost mechanism in personal Circles functions as intended, and such actions leave clear marks on the network topology.

We appreciate your thorough analysis of our invitation system and its potential interactions with multiple accounts. Your attention to these network dynamics contributes to a broader understanding of our system's design. Thank you for your participation in this security review.

[0xdanial]

@benjaminbollen, thanks for your comment.

with the current structure, the invite system doesn't make sense due to the following math:

• User can invite a new user every 4 days.
• This means approximately 7 invites per month.
• By the second month, user will have 49 invites.

Invite-based systems are usually implemented to make registration to the protocol more valuable and rare. That's why you have invitation costs and bonuses. However, if the structure allows users to invite almost unlimited people over time, it reduce the value of invites, rendering the whole inviting system pointless.

If you don't plan to change the structure, I think this report should at least be considered Low according to Hats Finance rules:

Issues where the behavior of the contracts differs from the intended behavior (as described in the docs and by common sense), but no funds are at risk.

Thanks

[0xarshia]

@benjaminbollen i want to firstly thank the sponsor for carefully checking the findings, shows the amount of passion they have for security of their protocol

however issue seems valid because bad actor literally abusing the functionality in order to break the system and break the logic of invitation cost and as this was designed in order to prevent exactly this abuse of system but we see it fails to protect badactor doing it so

so either logic is useless (its NOT and have great purpose) or issue is valid cause logic needs some changes in order to work as expected

and because there is no place in the doc specifying this is a "acceptable risk" hence again should be labled valid i think

otherwise in this platform sponsors would be able to dodge the paying prize by saying its "acceptable risk" this is why almost all the contest platforms require making acceptable risks transparent in contest start page.