Description:

The vulnerability in the function resolveTrick arises from the refund mechanism implemented in the contract. This mechanism allows the caller to send an amount of Ether which is higher than the required cost and receive the difference back as a refund. Here's where it becomes exploitable: if a user calls this function with msg.value that is purposely set to a high amount, the contract will process the refund without proper validation on whether it actually owns sufficient Ether to support the refund.

Exploit Steps:

1. Initial Setup:

   • Assume a user has initiated a purchase process using resolveTrick and the item cost (after being doubled) equals 2 ETH.

   • The user has previously paid 1 ETH during the initial transaction, logged in pendingNFTsAmountPaid[tokenId].

2. Execute Exploit:

   • The exploiter checks the contract's Ether balance, which let's assume is 3 ETH.

   • The user triggers the resolveTrick function with msg.value of 10 ETH, leading to totalPaid = 11 ETH.

3. Contract Processes Transaction:

   • Inside resolveTrick, the contract successfully verifies the condition totalPaid >= requiredCost (11 ETH >= 2 ETH), satisfying the purchase requirement.

   • It transfers the NFT as per standard execution.

4. Faulty Refund Begins:

   • After successfully transferring the ownership of NFT, the contract calculates the refund amount as totalPaid - requiredCost, which equals 11 ETH - 2 ETH = 9 ETH.

   • The contract processes the refund using (bool refundSuccess,) = msg.sender.call{value: refund}("""");

   • Since the contract's original balance was only 3 ETH and 2 ETH are claimed with the NFT purchase, it only has 1 ETH left but attempts to send back 9 ETH.

5. Outcome of Exploit:

   • This causes a failed transaction due to insufficient funds for the refund. However, depending on the contract's setup to handle failed calls (not shown), this can lock the contract funds or revert the whole NFT transfer, paradoxically benefitting the exploiter by forcing the contract into a confused state, essentially DOS'ing it (Denial-of-Service).

Points to Note:

• This exploit takes advantage of the fact that the contract does not check or ensure it has enough Ether to perform the refund action adequately.

• A practical dose applied implies a significant, if not full depletion of the contract's balance, creating scenarios where legitimate operations cannot proceed.

• Remediation would require implementing a check before attempting the refund to confirm enough balance or structuring refunds through a more failsafe mechanism like a pull over push refund strategy."