Snowman Merkle Airdrop

AI First Flight #10
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Submission Details
Severity: medium
Valid

Denial of Service (DoS) via Dust Attack in SnowmanAirdrop

Denial of Service (DoS) via Dust Attack in SnowmanAirdrop

Description

  • Whitelisted users are expected to claim their NFTs by providing a Merkle proof that matches their recorded data in the distribution tree

  • The claimSnowman function calculates the Merkle leaf dynamically using i_snow.balanceOf(receiver). Since any address can transfer small amounts of ERC20 tokens to another address without consent, an attacker can intentionally increase a user's balance. This modification changes the generated leaf hash at the time of claim, causing the Merkle verification to fail and the transaction to revert

// src/SnowmanAirdrop.sol
function claimSnowman(address receiver, bytes32[] calldata merkleProof, uint8 v, bytes32 r, bytes32 s)
external
nonReentrant
{
@> uint256 amount = i_snow.balanceOf(receiver);
@> bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(receiver, amount))));
// Fails if balance was changed by an external transfer (Dust Attack)
if (!MerkleProof.verify(merkleProof, i_merkleRoot, leaf)) {
revert SA__InvalidProof();
}

Risk

Likelihood:

  • An attacker monitors the mempool for claimSnowman transactions. // Occurs when an attacker front-runs claims with a 1-wei transfer

  • The attacker targets whitelisted addresses with a simple script. // Occurs when an attacker wants to prevent specific or all users from claiming.

Impact:

  • Users are permanently blocked from claiming their airdrop rewards.

  • Legitimate users lose gas fees for every failed (reverted) transaction attempt.

Proof of Concept

function testDOSDustAttack() public {
// 1. Attacker sends 1 wei of Snow to Alice before she claims
deal(address(snow), attacker, 1);
vm.prank(attacker);
snow.transfer(alice, 1);
// 2. Alice generates her signature for her expected balance
bytes32 digest = airdrop.getMessageHash(alice);
(uint8 v, bytes32 r, bytes32 s) = vm.sign(aliceKey, digest);
// 3. Impact: Alice attempts to claim but fails because her balance is now "2" instead of "1"
vm.prank(alice);
vm.expectRevert(abi.encodeWithSignature("SA__InvalidProof()"));
airdrop.claimSnowman(alice, AL_PROOF, v, r, s);
}

Recommended Mitigation

- 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);
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 19 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!