Raisebox Faucet

First Flight #50
Beginner FriendlySolidity
100 EXP
View results
Submission Details
Impact: high
Likelihood: high
Invalid

Sybil Abuse on first time user 0.005 sepolia eth causing theft of company funds and technical DoS for other actual users.

Root + Impact

The verification of new users only requires a wallet address for this function to be triggered.

Description


Normal Behavior:


The claimFaucetTokens function is designed to transfer 1,000 test tokens to users who respect the 3-day cooldown and send 0.005 Sepolia ETH if their address has not been recorded in the hasClaimedEth mapping.


Issue:


The "first-time user" check relies solely on the wallet address (msg.sender / faucetClaimer). An attacker can easily create an unlimited number of Ethereum EOAs, bypassing this check and repeatedly draining 0.005 Sepolia ETH for each new account.

// Root cause in the codebase with @> marks to highlight the relevant section
// file: RaiseBoxFaucet.sol
// State variable to track if ETH has been claimed
mapping(address => bool) private @>hasClaimedEth;
// Inside claimFaucetTokens()
if (!@>hasClaimedEth[faucetClaimer] && !sepEthDripsPaused) {
@>hasClaimedEth[faucetClaimer] = true;
(bool success,) = faucetClaimer.call{value: sepEthAmountToDrip}("");
}

Risk

Likelihood: High

  • Reason

This attack occurs immediately once the contract is funded with Sepolia ETH, as there is zero friction to create new EOAs and execute claims.

Attackers can automate thousands of account creations, draining funds quickly, limited only by block time and ga

s.


Impact:

  • Impact

Economic Loss/Theft: The contract’s Sepolia ETH balance can be siphoned rapidly, depleting funds intended for gas.

Denial of Service: Legitimate users are prevented from receiving the 0.005 Sepolia ETH necessary for protocol testing, effectively causing a DoS.

Proof of Concept

Explanation:


1. This creates ten accounts with a wallet address only each having claimed the free sepolia.

2. Once the ETH has been deposited to the wallet you can then send it wherever you like and 0.005 eth turns to 0.050 eth you can then

return with a 1,000,000 wallet attack and 0.005 eth turns to 5000 eth in about 15 minutes.

// test/ExploitSimulation.t.sol (Foundry/Forge Test)
pragma solidity ^0.8.19;
import "forge-std/Test.sol";
import "../src/RaiseBoxFaucet.sol";
contract ExploitSimulation is Test {
RaiseBoxFaucet faucet;
address owner;
function setUp() public {
owner = address(0xBEEF);
vm.prank(owner);
faucet = new RaiseBoxFaucet("TestToken", "TST", 1000 * 1e18, 0.005 ether, 100 ether);
vm.deal(address(faucet), 1 ether);
}
function testManyUniqueClaimers() public {
uint256 claimAmount = 0.005 ether;
uint256 initialFaucetBalance = address(faucet).balance;
uint256 n = 10; // Simulate 10 Sybil accounts
for (uint256 i = 0; i < n; ++i) {
address newUser = address(uint160(uint256(keccak256(abi.encodePacked("user", i)))));
vm.deal(newUser, 0);
vm.prank(newUser);
faucet.claimFaucetTokens();
}
uint256 finalFaucetBalance = address(faucet).balance;
assertEq(finalFaucetBalance, initialFaucetBalance - (claimAmount * n), "Faucet balance was not drained correctly.");
}
}

Recommended Mitigation

Explanation:


1. If you reduce the amount the faucet leaks its rewards for resources will become redundant into another place.

2. The puzzles are had for the bots to solve causing time consuming precisely coded playbooks and hardcore processing reducing the likelihood of the capacity for the attacks.

3. Adding the extra defense in depth previous and a simple identity check or log in prevents bot attacks and begins to cover your chain under UK fsfc restrictions.

4. Adding profiles after these checks that collaborate with the login and identity check will reduce the memory consumption with the sybil attacks.

- remove this code
+ add this code
// RaiseBoxFaucet.sol
// Mitigation 1: Reduce incentive for abuse
- uint256 public sepEthAmountToDrip; // Current 0.005 ether
+ uint256 public sepEthAmountToDrip = 100000000000000; // 0.000001 ETH
// Mitigation 2: Implement off-chain Sybil resistance
// 1. CAPTCHA/hCaptcha on web frontend
// 2. OAuth/social sign-in to associate claims with real users
// 3. IP/device rate-limiting at server layer
// Mitigation 3: On-chain friction (optional)
// Require proof-of-work (PoW) or token ownership to claim
// Prioritize external Sybil checks, or reduce reward.
Updates

Lead Judging Commences

inallhonesty Lead Judge 7 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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