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

Claim Amount Derived From Current Balance Instead of Snapshot

fabriziogiannitrapa

Claim Amount Derived From Current Balance Instead of Snapshot

Description

The claimSnowman function derives the claim amount from the user's current Snow balance (i_snow.balanceOf(receiver)) rather than from the Merkle tree leaf. The leaf is built as keccak256(bytes.concat(keccak256(abi.encode(receiver, amount)))), where amount is this current balance. For the Merkle proof to verify, the leaf must match a leaf in the tree, which was constructed from a snapshot of balances at a specific block.

The intended design is that the Merkle tree encodes the snapshot amount each user is entitled to. The claim should verify the proof against that snapshot amount and mint accordingly. Instead, the contract requires the user's current balance to exactly equal the snapshot amount. If the user has more Snow (e.g. earned or received after the snapshot) or less (e.g. transferred some away), the leaf hash changes and the proof fails.

// @> Root cause: amount comes from current balance, not from the tree/snapshot
uint256 amount = i_snow.balanceOf(receiver); // @> Must exactly match snapshot amount
​
// note but why putting the amount here? if user has slightly more or slightly less of the amount that he had when
// the root was created, he cannot claim again - bug I think the leaf should not encode the amount
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert SA__InvalidProof();
}

Risk

Likelihood (high):

  • Users naturally change their Snow balance over time via earnSnow(), transfers, or purchases.

  • The snapshot is taken at a fixed block; any balance change after that breaks the claim.

  • No special conditions required; normal usage leads to failed claims.

Impact (high):

  • Legitimate recipients with more or less Snow than their snapshot amount cannot claim.

  • Users who earned additional Snow after the snapshot are excluded despite being eligible.

  • Users who transferred some Snow away cannot claim their allocation.

Severity (high):

Proof of Concept

  1. Snapshot at block N: Alice has 50 Snow. Merkle tree includes leaf (alice, 50).

  2. Alice earns 1 Snow via earnSnow() before claiming. Her balance is now 51.

  3. amount = i_snow.balanceOf(alice) = 51. Leaf becomes hash(alice, 51).

  4. Merkle proof was generated for leaf hash(alice, 50). Proof fails; SA__InvalidProof().

  5. Alice cannot claim. Alternatively, if Alice transfers 10 Snow away, her balance is 40. Leaf hash(alice, 40) does not match proof for hash(alice, 50). Claim fails.

// Scenario: user earned more Snow after snapshot
// Snapshot: alice has 50 Snow, leaf = hash(alice, 50)
// alice earns 1 Snow -> balance = 51
uint256 amount = i_snow.balanceOf(alice); // 51
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(alice, 51))));
// Proof was for leaf hash(alice, 50) -> verification fails
MerkleProof.verify(proof, root, leaf); // false -> revert

Recommended Mitigation

Accept the snapshot amount as a parameter and use it for the leaf and mint. The user must hold at least that amount at claim time. The signature must also bind to the amount (e.g. include amount in the signed message).

- 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
{
// ...
- if (i_snow.balanceOf(receiver) == 0) {
+ if (i_snow.balanceOf(receiver) < amount) {
revert SA__ZeroAmount();
}
- if (!_isValidSignature(receiver, getMessageHash(receiver), v, r, s)) {
+ if (!_isValidSignature(receiver, amount, getMessageHash(receiver, amount), v, r, s)) {
revert SA__InvalidSignature();
}
- uint256 amount = i_snow.balanceOf(receiver);
bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
// ...
}

Update getMessageHash to accept amount as a parameter so the signature binds to the snapshot amount rather than the current balance.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 12 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.&#x20; ```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!