Snowman Merkle Airdrop
AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Severity: medium
Valid

Attacker can invalidate someone's claim by sending them 1 wei of Snow

redbud

Root + Impact

The SnowmanAirdrop.claimSnowman function does not take an amount as a parameter. Instead, it queries the receiver's balance on-chain at the moment of execution and uses that value for both EIP-712 signature verification and Merkle proof verification. This creates a "Front-running" vulnerability. An attacker can intentionally change a user's balance to make their pending transaction fail.

Description

If Alice has 5 tokens and wants to claim her NFTs:

  1. Alice generates a Merkle proof for amount = 5.

  2. Alice signs an EIP-712 message for amount = 5.

  3. Alice (or a relayer) submits the transaction.

  4. An attacker sees the transaction in the mempool.

  5. The attacker sends Alice 1 wei of Snow token via transfer.

  6. Alice's balance is now 5.000...001.

  7. The claimSnowman function executes, fetches the new balance, and fails to verify the signature/proof against the new amount.

This can be repeated indefinitely to prevent anyone from ever claiming.

// src/SnowmanAirdrop.sol
function claimSnowman(address receiver, ...) {
// ...
@> uint256 amount = i_snow.balanceOf(receiver);
// The signature and proof are tied to this dynamic 'amount'
@> bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert SA__InvalidProof(); }
}

Risk

Likelihood: Medium

  • Anyone can send tokens to anyone else.

  • Mempool monitoring is standard practice for bots.

Impact: High

  • Legitimate users can be completely locked out of their airdrop by a malicious party for a negligible cost.

  • Causes significant griefing and loss of user trust.

Proof of Concept

The PoC simulates a real-world scenario where a user, Alice, is prepared to claim her airdrop rewards. She has computed her Merkle proof and generated an EIP-712 signature based on her current balance of 100 Snow tokens. However, an attacker monitors the mempool and sends her exactly 1 wei of the Snow token.

Because the claimSnowman function fetchs Alice's balance on-chain during the transaction execution, it retrieves 100 ether + 1 wei. This value is then used to reconstruct the message hash and the Merkle leaf. Both the signature verification and the Merkle proof verification fail because they were originally generated for the 100 ether value. Alice's transaction reverts, and she is unable to claim her NFTs as long as the attacker continues to front-run her with tiny transfers.

function test_poc_BalanceGriefing() public {
// 1. Setup Alice's account and initial balance (100 tokens)
uint256 aliceKey = 0xA11CE;
address alice = vm.addr(aliceKey);
uint256 initialBalance = 100 * 10**18;
deal(address(snow), alice, initialBalance);
// 2. Setup Airdrop with Alice as a participant
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(alice, initialBalance))));
airdrop = new SnowmanAirdrop(leaf, address(snow), address(nft));
// 3. Alice signs a claim message for her 100 tokens
bytes32 digest = airdrop.getMessageHash(alice);
(uint8 v, bytes32 r, bytes32 s) = vm.sign(aliceKey, digest);
// 4. Attacker sends 1 wei to Alice, changing her balance
address attackerAddr = makeAddr("griefer");
deal(address(snow), attackerAddr, 1);
vm.prank(attackerAddr);
snow.transfer(alice, 1);
// 5. Alice attempts to claim with her original signature and proof
bytes32[] memory proof = new bytes32[](0);
vm.prank(alice);
snow.approve(address(airdrop), initialBalance + 1);
// 6. The claim reverts because the contract sees 'initialBalance + 1'
vm.expectRevert();
airdrop.claimSnowman(alice, proof, v, r, s);
console2.log("Attacker successfully griefed Alice by sending 1 wei");
}

Recommended Mitigation

Transfer the amount of Snow tokens the user intends to claim as a parameter to the function. Verify the signature and Merkle proof against this provided amount. After verification, use safeTransferFrom to take exactly that amount from the user. This makes the transaction independent of the user's total balance.

- function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
+ function claimSnowman(address receiver, uint256 amount, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
- uint256 amount = i_snow.balanceOf(receiver);
// ... verify signature and proof against the passed 'amount'
}
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 24 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[M-01] DoS to a user trying to claim a Snowman

# Root + Impact ## Description * Users will approve a specific amount of Snow to the SnowmanAirdrop and also sign a message with their address and that same amount, in order to be able to claim the NFT * Because the current amount of Snow owned by the user is used in the verification, an attacker could forcefully send Snow to the receiver in a front-running attack, to prevent the receiver from claiming the NFT.  ```Solidity function getMessageHash(address receiver) public view returns (bytes32) { ... // @audit HIGH An attacker could send 1 wei of Snow token to the receiver and invalidate the signature, causing the receiver to never be able to claim their Snowman uint256 amount = i_snow.balanceOf(receiver); return _hashTypedDataV4( keccak256(abi.encode(MESSAGE_TYPEHASH, SnowmanClaim({receiver: receiver, amount: amount}))) ); ``` ## Risk **Likelihood**: * The attacker must purchase Snow and forcefully send it to the receiver in a front-running attack, so the likelihood is Medium **Impact**: * The impact is High as it could lock out the receiver from claiming forever ## Proof of Concept The attack consists on Bob sending an extra Snow token to Alice before Satoshi claims the NFT on behalf of Alice. To showcase the risk, the extra Snow is earned for free by Bob. ```Solidity function testDoSClaimSnowman() public { assert(snow.balanceOf(alice) == 1); // Get alice's digest while the amount is still 1 bytes32 alDigest = airdrop.getMessageHash(alice); // alice signs a message (uint8 alV, bytes32 alR, bytes32 alS) = vm.sign(alKey, alDigest); vm.startPrank(bob); vm.warp(block.timestamp + 1 weeks); snow.earnSnow(); assert(snow.balanceOf(bob) == 2); snow.transfer(alice, 1); // Alice claim test assert(snow.balanceOf(alice) == 2); vm.startPrank(alice); snow.approve(address(airdrop), 1); // satoshi calls claims on behalf of alice using her signed message vm.startPrank(satoshi); vm.expectRevert(); airdrop.claimSnowman(alice, AL_PROOF, alV, alR, alS); } ``` ## Recommended Mitigation Include the amount to be claimed in both `getMessageHash` and `claimSnowman` instead of reading it from the Snow contract. Showing only the new code in the section below ```Python function claimSnowman(address receiver, uint256 amount, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s) external nonReentrant { ... bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))); if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) { revert SA__InvalidProof(); } // @audit LOW Seems like using the ERC20 permit here would allow for both the delegation of the claim and the transfer of the Snow tokens in one transaction i_snow.safeTransferFrom(receiver, address(this), amount); // send ... } ```

Support

FAQs

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

Give us feedback!