DatingDapp

First Flight #33
Beginner FriendlyFoundrySolidityNFT
100 EXP
View results
Submission Details
Severity: low
Invalid

Multiple Profile Creation Enables Social Engineering and Fund Locking (Insufficient Sybil Resistance + DoS of User Funds)

Description:

The mintProfile::soulboundNFT function allows users to create multiple profiles by using different wallet addresses, with no mechanisms in place to verify unique human identity. While the 2-of-2 multisig protects against direct theft of matched funds, the ability to create multiple fake profiles enables social engineering attacks and denial of service of user funds. The only existing check require(profileToToken[msg.sender] == 0, "Profile already exists") prevents the same wallet from creating multiple profiles but can be trivially bypassed by creating new wallets. This breaks the "soulbound" nature of the profile NFTs which are meant to represent unique individuals.

Impact:
The impact is HIGH due to:

  1. Ability to lock user funds in dormant multisigs (1 ETH per incident)

  2. Platform integrity compromise through fake profiles

  3. Mass identity fraud potential

  4. Enabling of sophisticated social engineering attacks

  5. Degradation of user trust and platform value proposition

Proof of Concept:
Attack Path for Fund Locking:

  1. Attacker creates multiple wallets and profiles with attractive characteristics

  2. Genuine users discover these profiles and pay 1 ETH to "like" them

  3. Attacker uses different fake profiles to create matches with victims

  4. 2-of-2 multisigs are created for each match

  5. Attacker never signs transactions on the multisigs

  6. Victims' funds (minus platform fee) remain locked indefinitely

  7. This creates a "graveyard" of unusable multisigs containing victim funds

Proof of Code:

function testMultipleWalletMinting() public {
// First wallet mints a profile
vm.prank(user);
soulboundNFT.mintProfile("Alice", 25, "ipfs://profileImage1");
uint256 firstTokenId = soulboundNFT.profileToToken(user);
assertEq(firstTokenId, 1, "First token ID should be 1");
// Second wallet mints a profile
vm.prank(user2);
soulboundNFT.mintProfile("Bob", 30, "ipfs://profileImage2");
uint256 secondTokenId = soulboundNFT.profileToToken(user2);
assertEq(secondTokenId, 2, "Second token ID should be 2");
// Verify both profiles exist and are owned by different addresses
assertEq(soulboundNFT.ownerOf(firstTokenId), user, "First profile should be owned by user");
assertEq(soulboundNFT.ownerOf(secondTokenId), user2, "Second profile should be owned by user2");
}

Recommended Mitigation:

  1. Implement Sybil resistance:

    • Integrate proof-of-personhood protocols like BrightID or Proof of Humanity

    • Require verifiable social media account linking

    • Implement phone number verification with rate limiting

    • Consider KYC integration for identity verification

  2. Add fund protection mechanisms:

    • Time-based fund return mechanism if multisig remains unused

    • Platform arbitration system for disputed/inactive matches

    • Gradual increase in "like" costs for new wallets

    • Cool-down periods between accepting matches

  3. Enhance profile verification:

    • Add stake-to-create requirements

    • Implement reputation scoring

    • Add cooldown periods between profile creations from same IP

    • Require profile verification steps before accepting matches

  4. Improve monitoring:

    • Track patterns of inactive multisigs

    • Monitor for coordinated profile creation

    • Flag suspicious matching patterns

    • Implement automated Sybil attack detection

The core focus should be on implementing strong identity verification before profile creation, combined with mechanisms to unlock funds from inactive matches.

Updates

Appeal created

n0kto Lead Judge 6 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

invalid_sybil_attack

Still have to pay to like anyone. No impact.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.