From Vulnerable to Secure: QuillAudits’ Impact on NFTs2Me

1.Information Gathering

• Collected and reviewed all relevant documentation, including whitepaper, technical specifications, and design documents.
• Obtained a clear understanding of the NFTs2ME platform's functionality and intended user interactions.
• Discussed client concerns and specific areas of focus for the audit.

2. Manual Code Review

Conducted a line-by-line review of the smart contract code, focusing on:

• Vulnerability identification: Searching for known vulnerabilities like reentrancy, front-running, integer overflows, and access control issues, etc.
• Logic flaws: Identifying inconsistencies or unintended behaviours in the code logic.
• Solidity best practices: Compliance with secure coding standards and adherence to established guidelines.

3. Functional Testing

• Developed and executed a comprehensive set of test cases covering various user interactions and edge cases.
• Leveraged tools like Hardhat to deploy and test the smart contract locally.

4. Automated Testing

• Employed static analysis tools like QuillShield to identify vulnerabilities through automated code scanning.
• Utilized symbolic execution tools like Mythril to explore various code execution paths and uncover potential attack vectors.
• Integrated unit tests are written by the NFTs2Me team to verify specific contract functions and their behavior.

5. Reporting & Remediation

• Prepared a detailed report outlining all identified vulnerabilities, categorized by severity and potential impact.
• Provided clear recommendations for fixing each vulnerability, including code snippets and best practices.
• Collaborated with the NFTs2ME Platform team to prioritize and address the identified issues.
• Conducted additional verification testing after vulnerability fixes were implemented.

Audit Discoveries

1. Denial-of-Service (DoS) Vulnerability

Discovery: The contract iterates over an array containing revenue addresses during withdrawals. This array lacks a defined upper limit on its size. If the array grows excessively large, iterating through it could exceed the gas limit, leading to a DoS attack.

Impact: An attacker could potentially exploit this vulnerability to prevent legitimate users from executing withdrawal functions by manipulating the revenue address array size.

2. Insecure Token Transfers

Discovery: The contract utilizes the transfer function for token withdrawals instead of the recommended safeTransfer function.

Impact: Tokens that are non-compliant with the ERC20 standard could return false on failed transfers using the transfer function. This failure would go unnoticed by the contract, potentially leading to unintended token behavior.

3. Missing Signature Expiry

Discovery: The signature verification process for delegated creation transactions lacks an expiry timestamp. This allows attackers to potentially reuse expired signatures for unauthorized actions.

Impact: An attacker could potentially obtain a valid signature and use it beyond its intended timeframe to execute unauthorized transactions on behalf of the signer.

4. Insecure Signature Verification

Discovery: The signature verification process in the delegatedCreation function has two vulnerabilities:

• Missing Verifying Contract Address: The contract address is not included in the signature verification hash. This could allow attackers to reuse a signature for a different contract version if the current contract is deprecated.

• Missing Nonce Check: The function does not verify that a unique nonce value is used for each signature. This allows attackers to potentially replay a signature for the same owner address on the same factory contract.

   

Remediation Strategies

1. Mitigating Denial-of-Service (DoS) Vulnerability

Action:

Imposed a defined upper limit on the size of the revenue address array in the N2MFactory contract.

Outcome:

Limiting the array size prevents excessive gas consumption during iteration, mitigating the risk of DoS attacks and ensuring smooth execution of withdrawal functions.

2. Securing Token Transfers

Action:

Implemented the safeTransfer function for token withdrawals in the N2MERC721A contract instead of the transfer function.

Outcome:

Using safeTransfer ensures compliance with the ERC20 standard, providing a more secure method for token transfers and preventing unnoticed transfer failures.

3. Implementing Signature Expiry

Action:

Add an expiry timestamp to the signature verification process in the delegatedCreation function of the N2MFactory contract.

Outcome:

Incorporating an expiry timestamp prevents the reuse of signatures beyond their intended timeframe, ensuring that signatures are only valid for a limited period and reducing the risk of unauthorized transactions.

4. Enhancing Signature Verification

Action:

1. Include the contract address in the signature verification hash in the delegatedCreation function of the N2MFactory contract.
2. Implement a unique nonce check for each signature in the delegatedCreation function.

Outcome:

Adding the contract address to the verification hash ensures that signatures are specific to a particular contract version. Implementing nonce checks prevents replay attacks, ensuring each signature is used only once per owner address on the factory contract.

During the audit, several functional tests were conducted to ensure the robustness and correctness of the NFTs2ME Platform smart contracts.

Let’s delve into some of the critical tests performed:

Collection Creation:

• Test Case: Verify a user can successfully create a new collection.
• Expected Outcome: The collection is created with the specified details, and the user is assigned ownership.

Multicall Functionality:

• Test Case: Verify the contract can execute multiple function calls within a single transaction using the multicall function.
• Expected Outcome: All included function calls are executed successfully within the transaction.

Owner Privileges:

• Test Case: Verify the owner can add a new contract implementation and signer address.
• Expected Outcome: The new implementation and signer are added to the contract's configuration.

Delegated Collection Creation:

• Test Case: Verify a user can create a collection on behalf of another user using a valid signature.
• Expected Outcome: The collection is created for the specified user, and the signature is verified successfully.

Collection Ownership Transfer:

• Test Case: Verify the owner can transfer ownership of a collection to another user.
• Expected Outcome: Ownership of the collection is successfully transferred to the new user.

Duplicate Signature Prevention:

• Test Case: Verify the contract prevents creating a collection using the same signature twice.
• Expected Outcome: The transaction reverts when attempting to use a previously used signature.

Salt Validation:

• Test Case: Verify the contract reverts if the salt used during collection creation contains an address other than the message sender.
• Expected Outcome: The transaction reverts to prevent unauthorized collection creation.

Multicall with Multiple Collections:

• Test Case: Verify the contract can execute multiple function calls across multiple collections within a single transaction using multicall with msg.value.
• Expected Outcome: All function calls are executed successfully on their respective collections, and the msg.value is distributed accordingly.

Critical State Variable Extraction:

• Test Case: Verify the contract can correctly identify critical state variables from provided bytes values.
• Expected Outcome: The contract successfully extracts and interprets the critical state variables.

Contract Initialization:

• Test Case: Verify contract initialization using packed data can only be performed once.
• Expected Outcome: Subsequent attempts to initialize the contract revert.

Public Sale Dates:

• Test Case: Verify minting functionality only allows minting within the defined end and drop dates during a public sale.
• Expected Outcome: Minting transactions revert outside the valid sale window.

Trait Management:

• Test Case: Verify only token owners can set and update traits for their tokens with an expiry time.
• Expected Outcome: Non-owners and transactions without valid ownership proof cannot modify traits.

Ownership Verification:

• Test Case: Verify the contract correctly identifies the updated owner of a token when the expiry time for the current owner is still valid.
• Expected Outcome: The contract recognizes the owner with a valid expiry time as the authorized owner.

Impressed by our findings and recommendations, the NFTs2Me developers promptly addressed all identified vulnerabilities. Through our collaborative efforts, the NFTs2Me project is now significantly more secure, ensuring the protection of user funds.

The NFTs2Me’s smart contracts security audit identified and addressed critical vulnerabilities, protecting user funds and ensuring platform stability. This case study demonstrates the importance of proactive security measures for blockchain-based projects, especially those dealing with financial assets. By conducting audits and addressing identified issues, the NFTs2Me Team has taken a significant step towards securing its platform and safeguarding user trust.