A Research Into Vulnerabilities in NFT Platforms

In our article from last week, we talked about NFT whitelist bypass vulnerabilities: A Research Into NFT Whitelist Bypass Vulnerability (1/2)

Now let’s continue to look into security issues in NFT platforms. There are two main types of NFT platforms, one is the NFT trading platform, such as: Opensea, TreasureDAO, etc.; the other is the platform that combines with Defi business, like Revest Finance. Different types of platforms have different business types, also with different security vulnerabilities.

NFT + DeFi type

Currently, there are three main types of NFT + DeFi: one is to use NFT as a liquidity token, e.g., Uniswap-V3; one is to fragment NFT, i.e., FNFT (Fractional Finance Non-Fungible Token), e.g., Revest Finance; the third is to use NFT as collateral for lending, such as: Position Exchange, etc. As Revest Finance project contains the above three business types, so we take Revest Finance as an example to investigate its security incident from the business logic perspective.

Revest Finance is a staking solution for the DeFi space. Users participating in any Defi staking through this project can directly generate an F-NFT, which represents the current and future value of the staking position, with the following business model.

The project allows the user to mint FNFT of the corresponding collateral asset via mintAddressLock(), as shown in the following code.

The important parameters involved are:

- trigger: only that address can unlock the staked asset.

- recipients: the recipients corresponding to the minted FNFT.

- quantities: the number of FNFTs received by each recipient.

- IRevest.FNFTConfig: describes the staked assets corresponding to the FNFT, including: asset (type of asset staked, such as WETH, etc.), depositAmount (number of staked assets represented by each FNFT, including precision), etc.

The user can also add FNFT’s collateral assets via depositAdditionalToFNFT() with the following code.

The important parameters involved are:

- fnftId: the FNFT to which the asset needs to be added.

- amount: the number of additional collateral assets required per FNFT, including precision.

- quantity: the number of FNFTs for which additional collateral is provided.

When users add pledged assets, there are three cases depending on the quantity, the first case is to add pledge for all FNFTs, the second case is to add pledge for some of them, and the third case is to add pledge for a number of FNFTs greater than the total number of FNFTs, at which time an error is reported back. The vulnerability is the reentrancy caused in the second case, and the specific logic is as follows.

From the above code, it can be seen that the additional collateral needs to burn the previous FNFT first, and then mint the new FNFT afterwards. During minting, as the min() function does not determine whether the FNFT to be minted already exists, and the state variable fnftId is self-minted after the _mint() function. And there is a hidden external call _doSafeTransferAcceptanceCheck() in _min() in ERC-1155, which causes a reentrancy vulnerability. The specific code is as follows.

The mint() function here in _mint() contains a hidden external call, as follows.

The attack consists of the following three main steps.

1. Call mintAddressLock() to mint 2 FNFTs with fnftId 1027, but their corresponding assets are 0.

2. Call mintAddressLock() to mint 360,000 FNFTs with fnftId of 1028, whose corresponding collateral assets remain 0.

3. In step 2, the _doSafeTransferAcceptanceCheck() in the _mint() function inERC-1155 is used to re-enter the depositAdditionalToFNFT() to update the collateral corresponding to 1 FNFT with fnftId of 1027 to 1 WETH. Since at this point fnftId has not yet self-minted and is still 1027, the function generates an FNFT with fnftid of 1028 and a value of 1 WETH, resulting in updating the value of the FNFT with id 1028 from 0 to 1 WETH.

In summary, since FNFT is a securitized NFT, its value will fluctuate depending on the business logic, such as the value of the staking position in this example. Therefore, there are cases of value changes in FNFT, which are generally implemented by rewriting functions such as burn() and mint(), e.g., the FNFTHandler contract in this example. If the implementation does not consider the Checks-Effects-Interactions mechanism, there may be serious security issues.

NFT Trading Platform

This type of platform will generally implement simple market functions, including: pending orders, cancel pending orders, purchase, bid, cancel bids, accept bids, withdrawals, etc.. The NFT assets involved include ERC721 and ERC1155, and the development process may cause security problems, such as the TreasureDAO incident, if the difference between the two is not taken into account.

On March 3, 2022, the TreasureDAO ecosystem’s TreasureMarketplace trading platform was hacked, resulting in the theft of 100+ NFT tokens. Read more in Beosin’s Analysis of the Arbitrum-based TreasureDAO exploit: Almost all Hacked NFTs Have been Returned.

The related information is as follows.

Transaction initiation address.

Arbitrum：0x9b1acd4336ebf7656f49224d14a892566fd48e68

Vulnerable Contracts.

Arbitrum：0x812cda2181ed7c45a35a691e0c85e231d218e273

Attack Transactions.

Arbitrum: 0x57dc8e6a28efa28ac4a3ef50105b73f45d56615d4a6c142463b6372741db2a2b

The buyItem function of the TreasureMarketplaceBuyer contract does not make a token type judgement after passing in the _quantity parameter, and directly multiplies _quantity with _pricePerItem to calculate totalPrice, so the safeTransferFrom function can call the buyItem function of the TreasureMarketplace contract to buy tokens when the ERC-20 token payment amount is only 0.

However, when calling the buyItem function of the TreasureMarketplace contract, the function only makes a judgment on the type of tokens purchased and does not make a non-zero judgment on the number of tokens, resulting in a vulnerability exploit where ERC-721 tokens can be purchased directly without regard to the _quantity value.

Among the vulnerabilities related to the NFT trading platform, in addition to the above-mentioned vulnerabilities caused by NFT itself, there are also cases where NFT transactions are jeopardized due to security issues on the platform itself. For example, the recently discovered Opensea Wyvern 2.2 contract vulnerability, which could be used by attackers to steal WETH from users with active offers in the Opensea marketplace, was fortunately discovered in advance by the Opensea team and fixed in a timely manner, and no related attacks have yet been generated.