June 24, 2022

A Research Into NFT Whitelist Bypass Vulnerability

The lifecycle of an NFT is usually divided into phases such as issuance, circulation and burning, among which many of the security issues can be seen in the issuance phase. The purchase of NFT is usually divided into two cases: pre-sale and official sale. In the pre-sale stage, NFT projects usually can set up a whitelist of users who can participate. Despite the settings are made, there are still various types of whitelist bypass vulnerabilities.

Case 1 BAYC airdrop event

On March 17, 2022, a twitter user Will Sheehan tweeted that an MEV bot got over 60,000 APE Coin airdrops through flashloan.

The relevant information is as follows:

Tx:

0xeb8c3bebed11e2e4fcd30cbfc2fb3c55c4ca166003c7f7d319e78eaab9747098

Profited address:

0x6703741e913a30D6604481472b6d81F3da45e6E8

Contract address with vulnerability:

0x025C6da5BD0e6A5dd1350fda9e3B6a614B205a1F

The transaction in which the attacker obtains the relevant APE airdrop is shown in the following figure.

The main steps of the arbitrage:

1. First purchase BAYC NFT with ID 1060 from Opensea.

2. Flashloan 5 BAYC NFTs via NFTX.

3. Exploit the AirdropGrapesToken vulnerability to claim 6 BAYCs corresponding to the number of APE Coin.

4. Repay the flashloan and transfer of profitable APE Coin.

The code of the AirdropGrapesToken contract:

As shown above, this function uses alpha.balanceOf() and beta.balanceOf() to determine the caller’s ownership of the BAYC/MAYC NFT. However, this approach only captures the transient state of the user’s ownership of the NFT, which can be manipulated through flashloan. A safer approach is to use a Merkle tree based off-chain snapshot approach. This method stores the whitelist on the central server of the off-chain project party. When the user clicks mint on the front-end website, the server generates Merkle proof based on the wallet address, and the user then sends a transaction carrying Merkle proof to the smart contract and verifies it in the on-chain smart contract.

The approach generally consists of the following three parts.

- Backend generation of Merkle trees based on whitelist addresses.

- Uploading Merkle Root to the blockchain.

- The front-end generates a Merkle Proof based on the current user during validation and passes it into the NFT contract for verification.

For details, please refer to the NFT project Invisible Friends (INVSBLE). Contract address:0x59468516a8259058baD1cA5F8f4BFF190d30E066.

The following is the whitelist minting method mintListed() adopted in the INVSBLE project.

- amount: the number of minting NFTs.

- maxAmount: the maximum number of NFTs that can be minted at this address.

- merkleProof: determine whether a particular whitelisted address node belongs to the required data on the merkle tree, including leaf nodes, paths, and roots.

The function first checks whether the pre-sale is on and whether the caller still has a quota for minting, then performs a whitelist check and verifies that the caller’s bid is correct, and finally mints NFT. The following is the code implementation to perform the whitelist verification.

In this function, keccak256(abi.encodePacked(sender,maxAmount.toString())) is used to compute the leaf nodes of the Merkle tree, where the whitelisted user address and the maximum number of NFTs each user can mint are used as leaf node attributes. A check is also hidden that the msg.sender must be the whitelist address itself.

MerkleProof validation is calculated using library MerkleProof, the calculation process can be referred to SPV validation, and the source code is as follows.

With this approach, the entire whitelist does not need to be stored in the NFT issuance contract, only the Merkle root. when the transaction sender is a non-whitelisted user, it will not pass the checks because it cannot provide a legitimate MerkleProof.

There is another way of using signatures for off-chain data snapshot verification whitelisting, which is also prone to security problems if contract developers do not set up sufficient security checks at this point, e.g., the NBA arbitrage incident on April 21, 2022.

Case 2 NBA arbitrage incident

On April 21, 2022, the NBAxNFT project tweeted that its pre-sale sold out prematurely due to a problem with its allow list checks.

In this event, the vulnerable contract address is as follows:

0xdd5a649fc076886dfd4b9ad6acfc9b5eb882e83c

The above code has two security issues: signature impersonation and signature reuse. Signature reuse means that the same signature can only be used once. Generally, the project will set up a mapping structure in the contract to store whether the signature has been used or not, and the source code is as follows.

mapping(bytes => bool) private usedClaimSignatures

The bytes represent the Hash signature data, and the bool value represents whether the signature has ever been used, but the value is not stored in the mint_approved() function, so there is a signature reuse issue.

We focus on the problem of signature impersonation in whitelist verification here, i.e., the signature can be impersonated due to the vData memory parameter info not being verified by msg.sender when the parameter is passed. The whitelist verification function verify() is as follows:

The above code uses signature verification to verify the whitelist, which is stored on the centralized server. When a user clicks mint from the front-end NFT website, the server will first verify whether the user is a whitelist user. If yes, the server will use the project’s private key to sign, and then return the signature data. Finally, the user carries this signed transaction sent to the chain for verification. So here ecrecover() verifies only the address of the project owner, which only proves that the signature data is issued by the project owner, but the signature can be impersonated as the caller in the signature data, i.e. info.from, is not verified.

We will continue to talk about the security issues in NFT platforms in our next research. Stay tuned!