code-423n4/2024-08-phi-validation

Insufficient Validation in createArt Allows Manipulation of NFT Creation and Unauthorized Credential Issuance

c4-bot-3 opened this issue · 0 comments

c4-bot-3 commented

Lines of code

https://github.com/code-423n4/2024-08-phi/blob/8c0985f7a10b231f916a51af5d506dd6b0c54120/src/PhiFactory.sol#L196
https://github.com/code-423n4/2024-08-phi/blob/8c0985f7a10b231f916a51af5d506dd6b0c54120/src/PhiFactory.sol#L589

Vulnerability details

SUMMARY

The vulnerability within the smart contract lies in the insufficient validation and verification process during the creation of the credentials (Creds). Specifically, the issue resides in the createArt function of the PhiFactory contract, where user-defined input data can be manipulated without adequate checks. The core problem is the lack of robust validation for the signedData_ and signature_ inputs.

The current validation mechanism in the validateArtCreationSignature function is insufficient because it only verifies the authenticity of the signature and the expiration time, without performing comprehensive checks on the actual content of the signedData. This means that while the data may be signed by a trusted entity, the system fails to ensure that the data itself is not malicious or manipulated. As a result, an attacker can craft harmful data that, despite being correctly signed, bypasses these superficial checks and leads to unauthorized or fraudulent art creation within the contract, ultimately compromising the integrity and security of the system.

RELEVANT CODE

  • The createArt function from src/PhiFactory.sol:
function createArt(
    bytes calldata signedData_,
    bytes calldata signature_,
    CreateConfig memory createConfig_
)
    external
    payable
    nonReentrant
    whenNotPaused
    returns (address)
{
    _validateArtCreationSignature(signedData_, signature_);
    (, string memory uri_, bytes memory credData) = abi.decode(signedData_, (uint256, string, bytes));
    ERC1155Data memory erc1155Data = _createERC1155Data(artIdCounter, createConfig_, uri_, credData);
    address artAddress = createERC1155Internal(artIdCounter, erc1155Data);
    artIdCounter++;
    return artAddress;
}
  • Relevant internal calls:
    • _createERC1155Data: Packages data related to art creation, largely influenced by incoming signed data.
    • createERC1155Internal: Handles the instantiation or interaction with existing ERC1155 art contracts, again without sufficient validation on incoming inputs.

VULNERABILITY DETAILS

The vulnerability stems from how the createArt function processes its input parameters, specifically signedData_ and signature_. This data undergoes minimal validation, allowing an attacker to craft these inputs to manipulate the system maliciously. The createArt method is intended to facilitate the deployment or customization of art assets by processing these inputs and orchestrating the appropriate storage or contract interactions. However, without stringent validation or interface enforcement, it creates unintended pathways for exploitation.

The flow begins with _validateArtCreationSignature, aiming to assert the integrity of signedData_ and signature_ through the recovery of the signer's address. Still, this validation is only as strong as the assumptions it makes about the underlying cryptographic processes and the integrity of data sources.

Once past preliminary validation, manipulated data can alter or even subvert the intended logic wrapped in subsequent internal function calls. During the construction of the ERC1155Data object, inaccurate or crafted inputs might bypass expected controls due to insufficient logical checks. In particular, any assumptions on the structure or authenticity of returned addresses, like those representing bonding strategies or verifiers, can be corrupted, introducing malicious entities that respond falsely during their respective critical operations.

Furthermore, the ecosystem's emphasis on flexibility allows for dynamic contract upgrades, utilizing UUPS patterns across contracts like Cred, PhiFactory, and associated endpoints. Without rigorous input validation, this dynamic nature inadvertently amplifies the vulnerability's impact, as attacker-influenced data runs the risk of being propagated throughout multiple contract upgrades and interactions.

This vulnerability, by allowing attackers to leverage manipulated data inputs at a critical interaction node, undermines the system's foundational trust and can lead to unauthorized deployment or alterations to art assets, reflecting a systemic issue also seen in similar incidents such as the Ajna protocol case.

TECHNICAL IMPACT

The vulnerability in the createArt function of the PhiFactory contract primarily results in a breakdown of trust in the system due to inadequate input validation and signature verification. This flaw can be exploited to manipulate the creation and configuration of credentials (Creds) and associated art (NFTs), undermining the integrity, authenticity, and reliability of the protocol's credentialing process.

When an attacker crafts malicious input parameters for the createArt function, they can manipulate essential components in several ways:

  1. Unauthorized NFT Creation:

    • By exploiting the insufficient validation of the signedData_ and signature_ parameters, an attacker can create unauthorized or fraudulent NFTs linked to manipulated credential data.
    • The ERC1155Data object, derived from the signedData_, is assembled without stringent checks, allowing for potential insertion of rogue data. This can lead to the creation of NFTs that falsely represent onchain credentials or any entity the attacker wishes to counterfeit.

  2. Compromising System Integrity:

    • The usage of external, unverified data sources (e.g., malicious bonding curves or verifiers) as returned addresses in the credData can have adverse effects. These malicious entities can return deceptive data during their interactive processes, compelling logical operations to generate unintended outcomes.
    • Since the protocol depends heavily on the credibility of supplied data, any corruption here introduces systemic faults, where fraudulent data could result in erroneous representations within the blockchain identity framework.

  3. Financial Exploits:

    • Exploiting this vulnerability may lead to financial repercussions, such as unauthorized minting of NFTs leading to undue financial benefits towards the attacker through potential resale or credential manipulation.
    • A breached bonding curve or reward process can be subverted to yield excessive mint rewards or manipulated fees, bypassing the intended distribution logic, which stalls the equitable and rightful distribution of protocol incentives.

  4. Erosion of Trust:

    • At a broader level, the ability for an attacker to infiltrate such a central function with manipulated inputs and generate valid-seeming credentials directly attacks the protocol's credibility.
    • Users and participants rely on the immutability and transparency of blockchain credentials. This vulnerability, therefore, threatens the philosophical underpinning of decentralized identity and reputation systems.

These issues can be traced back to a lack of comprehensive cross-checking in functions such as _createERC1155Data and createERC1155Internal. By failing to enforce thorough validation and by overlooking the necessity for explicit interface implementations among interacting components, the protocol opens itself to exploits that potentially echo vulnerabilities similar to those observed in historical examples, such as the Ajna protocol exploit.

In summary, the current deficiencies in input validation and interface verification within the createArt functionality and related processes lead to multiple potential exploit vectors that can critically undermine the protocol's integrity, financial fairness, and overall trustworthiness.

PROOF OF CONCEPT

To exploit the identified vulnerability in the createArt function within the PhiFactory contract, we can construct a proof of concept (PoC) demonstrating how a malicious actor might manipulate the process to create unauthorized or fraudulent NFTs. Here’s a detailed explanation and step-by-step illustration of the exploit:

  1. Deploy a Malicious Contract:

    • The first step is to deploy a malicious contract that can simulate functions expected from valid bonding curves or verifiers but with manipulated return values to control the outcomes of critical operations.

  2. Preparation of Fake Input Data:

    • Craft signedData_ and signature_ that appear legitimate but are constructed to introduce the malicious contract as part of the credential creation process. This involves forging the data structure that these components use to convey credible-looking but harmful parameters, such as a bonding curve address.

  3. Invoke the createArt Function:

    • Utilize the createArt function of the PhiFactory contract with the forged data and point it to the deployed malicious contract. This triggers the creation process based on manipulated data.

  4. Manipulation Verification:

    • The manipulation will exploit the lack of strong validation for these parameters, allowing the malicious contract to pass through as if it were a legitimate bonding curve or verifier. Operations that interact with these contracts will receive manipulated responses, promoting the creation of counterfeit or unauthorized NFTs.

  5. Outcome Demonstration:

    • Observe the outcomes when the returned information from the malicious contract influences further process steps, such as the bonding curve's price determination or verifier eligibility checks, highlighting how an attacker gains control over NFT creation.

Breakdown of Functions and Interactions

  • Malicious Contract Structure:

    contract MaliciousBondingCurve {
    function getPrice(uint256, uint256) external pure returns (uint256) {
        // Return a manipulated price value
        return 0;
    }

    function getPriceData(uint256, uint256, uint256, bool) external pure returns (uint256, uint256, uint256) {
        // Provide crafted data to manipulate process
        return (0, 0, 0);
    }
}

  • Exploit Execution:

    contract Exploit {
    IPhiFactory public phiFactory;
    MaliciousBondingCurve public maliciousContract;

    constructor(IPhiFactory _phiFactory) {
        phiFactory = _phiFactory;
        maliciousContract = new MaliciousBondingCurve();
    }

    function executeExploit() public {
        bytes memory signedData = createFakeSignedData();
        bytes memory signature = createFakeSignature(signedData);

        phiFactory.createArt(signedData, signature, createConfig());
    }

    function createFakeSignedData() private view returns (bytes memory) {
        // Mock signed data payload
        return abi.encode(block.timestamp + 1 days, "http://fake-uri.com", abi.encode(address(maliciousContract)));
    }

    function createFakeSignature(bytes memory data) private pure returns (bytes memory) {
        // Mocked signature creation
        return abi.encodePacked(keccak256(data));
    }

    function createConfig() private pure returns (CreateConfig memory) {
        // Construct a config pointing to the malicious contract
        return CreateConfig({
            artist: msg.sender,
            receiver: msg.sender,
            maxSupply: 100,
            mintFee: 0.01 ether,
            startTime: block.timestamp,
            endTime: block.timestamp + 2 days,
            soulBounded: false
        });
    }
}

  • PoC Explanation:

    • MaliciousBondingCurve: Deploys a substitute contract for legitimate contracts required by createArt. It can deceive calls for price determination or verification steps.
    • Exploit: Constructs necessary data to invoke createArt with manipulated inputs. The signedData_ and signature_ are faked to point to MaliciousBondingCurve as the bonding curve/contract, bypassing typical security checks.
    • Outcome: Demonstrates a successful manipulation due to unchecked parameters, resulting in unauthorized NFT creation, echoing the past Ajna exploit.

The PoC exploits inadequate parameter validation within the createArt function, revealing critical flaws in how input data is processed and verified. A malicious actor could leverage this flaw, create unauthorized credentials, and affect the integrity and functionality of the Phi Protocol system.

Assessed type

Invalid Validation