Santa's List

AI First Flight #3
Beginner FriendlyFoundry
EXP
View results
Submission Details
Severity: high
Valid

Denial of Service (DoS) via State Manipulation in `SantasList::collectPresent`: Malicious Actors Can Permanently Block Legitimate Users from Rewards via checkList Manipulation

Denial of Service (DoS) via State Manipulation in SantasList::collectPresent:
Malicious Actors Can Permanently Block Legitimate Users from Rewards via checkList Manipulation

Description

The collectPresent function requires that s_theListCheckedOnce and s_theListCheckedTwice exactly match the same status (NICE/NICE or EXTRA_NICE/EXTRA_NICE) to grant rewards.

If a user's state is inconsistent (e.g., NICE on checkList but EXTRA_NICE on checkTwice), the function reverts with SantasList__NotNice(), permanently blocking the user from collecting their present.

function collectPresent() external {
if (block.timestamp < CHRISTMAS_2023_BLOCK_TIME) {
revert SantasList__NotChristmasYet();
}
if (balanceOf(msg.sender) > 0) {
revert SantasList__AlreadyCollected();
}
@> if (s_theListCheckedOnce[msg.sender] == Status.NICE && s_theListCheckedTwice[msg.sender] == Status.NICE) {
_mintAndIncrement();
return;
} else if (
@> s_theListCheckedOnce[msg.sender] == Status.EXTRA_NICE && s_theListCheckedTwice[msg.sender] == Status.EXTRA_NICE
) {
_mintAndIncrement();
i_santaToken.mint(msg.sender);
return;
}
@> revert SantasList__NotNice();
}

Risk

Likelihood: High

  • The checkList function has no access control, meaning anyone can call it. The attack vector is trivial (one function call).

Impact: High

  • Users with mixed status states are permanently denied their rewards.

  • As checkList is vulnerable with missing access control, attackers can intentionally set mixed states to DoS specific user (or group of them).

  • The user is eligible (Santa verified them on checkTwice), but they are permanently blocked because the attacker corrupted their state on checkList

  • Loss of users trust for the protocol

Proof of Concept:

The SantasList::collectPresent function requires s_theListCheckedOnce and s_theListCheckedTwice to match exactly. However, the checkList function lacks access control, allowing any user to arbitrarily set the checkList status.

An attacker can exploit this to:

  1. Target legitimate users who have been verified by Santa on checkTwice.

  2. Call checkList to set their status to a conflicting value (e.g., if checkTwice is NICE, set checkList to EXTRA_NICE).

  3. When the victim attempts to collectPresent(), the function reverts due to the mismatch, permanently denying them their reward.

This effectively turns a simple state check into a Denial of Service vector against any user the attacker can target.

function test_DoS() public {
// 1. Legitimate state: User verified by Santa on checkList & checkTwice as (NICE)
vm.prank(santa);
santasList.checkList(user, SantasList.Status.NICE);
santasList.checkTwice(user, SantasList.Status.NICE);
// 2. ATTACK: Attacker corrupts checkList to mismatch
// (Exploiting the missing access control in checkList)
address attacker = makeAddr("attacker");
vm.prank(attacker); // Or vm.prank(user) if self-DoS is the goal
santasList.checkList(user, SantasList.Status.EXTRA_NICE);
// Now, the user status is `EXTRA_NICE` on checkList and `NICE` on checkTwice
// 3. Legitimate user is blocked from collecting
// Advancing time to after Christmas
vm.warp(1_703_480_381 + 1);
// User tries to `collectPresent`, but it will revert!
vm.prank(user);
vm.expectRevert(SantasList.SantasList__NotNice.selector);
santasList.collectPresent(); // DoS confirmed!
}

Recommended Mitigation

We have two solutions here:

The BEST Fix:

  • Eliminates the Attack Vector: Remove the checks for s_theListCheckedOnce and base the reward logic solely on s_theListCheckedTwice. (Recommended)

  • Reward logic still correctly distinguishes between NICE and EXTRA_NICE based on the authoritative source (Santa)

  • Since checkList is no longer checked, an attacker can no longer corrupt the user's state to cause a DoS.

function collectPresent() external {
if (block.timestamp < CHRISTMAS_2023_BLOCK_TIME) {
revert SantasList__NotChristmasYet();
}
if (balanceOf(msg.sender) > 0) {
revert SantasList__AlreadyCollected();
}
- if (s_theListCheckedOnce[msg.sender] == Status.NICE && s_theListCheckedTwice[msg.sender] == Status.NICE) {
+ if (s_theListCheckedTwice[msg.sender] == Status.NICE) {
_mintAndIncrement();
return;
} else if (
- s_theListCheckedOnce[msg.sender] == Status.EXTRA_NICE && s_theListCheckedTwice[msg.sender] == Status.EXTRA_NICE) {
+ s_theListCheckedTwice[msg.sender] == Status.EXTRA_NICE) {
_mintAndIncrement();
i_santaToken.mint(msg.sender);
return;
}
revert SantasList__NotNice();
}

Alternative:

  • If the business logic strictly requires both checks , then the checkList function must be fixed first by adding the onlySanta modifier

  • However, given the current vulnerability, the safest immediate fix is to trust checkTwice only.

// Long term solution if both checks are strictly required
- function checkList(address person, Status status) external {
+ function checkList(address person, Status status) external onlySanta {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
Updates

Lead Judging Commences

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

[H-01] Anyone is able to call `checkList` function in SantasList contract and prevent any address from becoming `NICE` or `EXTRA_NICE` and collect present.

## Description With the current design of the protocol, anyone is able to call `checkList` function in SantasList contract, while documentation says only Santa should be able to call it. This can be considered as an access control vulnerability, because not only santa is allowed to make the first check. ## Vulnerability Details An attacker could simply call the external `checkList` function, passing as parameter the address of someone else and the enum Status `NAUGHTY`(or `NOT_CHECKED_TWICE`, which should actually be `UNKNOWN` given documentation). By doing that, Santa will not be able to execute `checkTwice` function correctly for `NICE` and `EXTRA_NICE` people. Indeed, if Santa first checked a user and assigned the status `NICE` or `EXTRA_NICE`, anyone is able to call `checkList` function again, and by doing so modify the status. This could result in Santa unable to execute the second check. Moreover, any malicious actor could check the mempool and front run Santa just before calling `checkTwice` function to check users. This would result in a major denial of service issue. ## Impact The impact of this vulnerability is HIGH as it results in a broken mechanism of the check list system. Any user could be declared `NAUGHTY` for the first check at any time, preventing present collecting by users although Santa considered the user as `NICE` or `EXTRA_NICE`. Santa could still call `checkList` function again to reassigned the status to `NICE` or `EXTRA_NICE` before calling `checkTwice` function, but any malicious actor could front run the call to `checkTwice` function. In this scenario, it would be impossible for Santa to actually double check a `NICE` or `EXTRA_NICE` user. ## Proof of Concept Just copy paste this test in SantasListTest contract : ``` function testDosAttack() external { vm.startPrank(makeAddr("attacker")); // any user can checList any address and assigned status to naughty // an attacker could front run Santa before the second check santasList.checkList(makeAddr("user"), SantasList.Status.NAUGHTY); vm.stopPrank(); vm.startPrank(santa); vm.expectRevert(); // Santa is unable to check twice the user santasList.checkTwice(makeAddr("user"), SantasList.Status.NICE); vm.stopPrank(); } ``` ## Recommendations I suggest to add the `onlySanta` modifier to `checkList` function. This will ensure the first check can only be done by Santa, and prevent DOS attack on the contract. With this modifier, specification will be respected : "In this contract Only Santa to take the following actions: - checkList: A function that changes an address to a new Status of NICE, EXTRA_NICE, NAUGHTY, or UNKNOWN on the original s_theListCheckedOnce list." The following code will resolve this access control issue, simply by adding `onlySanta` modifier: ``` function checkList(address person, Status status) external onlySanta { s_theListCheckedOnce[person] = status; emit CheckedOnce(person, status); } ``` No malicious actor is now able to front run Santa before `checkTwice` function call. The following tests shows that doing the first check for another user is impossible after adding `onlySanta` modifier: ``` function testDosResolved() external { vm.startPrank(makeAddr("attacker")); // checklist function call will revert if a user tries to execute the first check for another user vm.expectRevert(SantasList.SantasList__NotSanta.selector); santasList.checkList(makeAddr("user"), SantasList.Status.NAUGHTY); vm.stopPrank(); } ```

Support

FAQs

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

Give us feedback!