Full Report
HypeBears is a collectable set of NFT bears. mint is used to create new bears within this ecosystem. When minting the NFTs, the code uses _safeMint from the OZ reference implementation. There is a map that checks to see whether or not a given address has minted an NFT. The safe is in regards to a check for the onERC721Received hook if it's a contract and has nothing to do with security. The addressMinted is added at the end of the function. This violates the check-effects-use pattern. As a result, an attacker can mint the NFT and implement the hook within the _safeMint() function. Since the variable was not set, we can reenter the mintNFT function to create another one. Of course, this can be done as long as we can enough gas. Overall, a fairly standard reentrancy vulnerability but fun to read about in 2022 none-the-less.
Analysis Summary
# Incident Report: HypeBears Minting Reentrancy Vulnerability
## Executive Summary
The HypeBears NFT project suffered a reentrancy attack during its minting phase due to a flaw in the `mintNFT` function. By exploiting the `onERC721Received` hook in a standard OpenZeppelin implementation combined with a "Checks-Effects-Interactions" violation, an attacker was able to bypass "one-per-wallet" restrictions. This allowed the attacker to mint significantly more NFTs than intended, bypassing the project's logic constraints.
## Incident Details
- **Discovery Date:** Early 2022
- **Incident Date:** February 2022
- **Affected Organization:** HypeBears
- **Sector:** Web3 / Decentralized Finance (DeFi) / NFTs
- **Geography:** Global / Decentralized
## Timeline of Events
### Initial Access
- **Date/Time:** February 2022
- **Vector:** Smart Contract Exploitation (Reentrancy)
- **Details:** The attacker utilized a malicious contract to call the HypeBears `mintNFT` function. Because the project used `_safeMint`, the contract triggered a callback to the attacker's contract.
### Lateral Movement
- **Not Applicable:** The attack was a direct interaction with a public smart contract on the blockchain rather than a traditional network breach.
### Data Exfiltration/Impact
- **Details:** The attacker successfully circumvented the `addressMinted` mapping. By re-entering the mint function before the state variable was updated to "true," the attacker minted an arbitrary number of NFTs (limited only by gas) into a single wallet, violating the project’s intended scarcity and distribution rules.
### Detection & Response
- **Detection:** Discovered via on-chain monitoring and community reports regarding anomalous minting patterns from single addresses.
- **Response:** Post-incident analysis was conducted to identify the vulnerability in the contract code.
## Attack Methodology
- **Initial Access:** Direct interaction with the HypeBears smart contract.
- **Persistence:** Not applicable; the attack was automated via an exploit contract.
- **Privilege Escalation:** Bypassing logic gates to gain unauthorized minting rights.
- **Impact:** The attacker utilized the `onERC721Received` hook within the `_safeMint()` function to re-enter the caller function before the `addressMinted` status was updated.
## Impact Assessment
- **Financial:** Dilution of NFT value due to unauthorized supply increase and loss of potential revenue from fair minting.
- **Data Breach:** None (Public blockchain data).
- **Operational:** Disruption of the NFT launch phase.
- **Reputational:** Significant loss of community trust due to the "standard" nature of the vulnerability.
## Indicators of Compromise
- **Behavioral indicators:** Single contract addresses calling the `mint` function multiple times in a single transaction or recursive loop.
- **Contract indicators:** Systematic use of the `onERC721Received` callback to trigger secondary functions.
## Response Actions
- **Containment:** Community alerted to the exploit.
- **Eradication:** Identification of the specific logical error in the contract code (CEI pattern violation).
- **Recovery:** Development of post-mortem reports to educate the community and developers.
## Lessons Learned
- **Pattern Adherence:** Strictly following the **Checks-Effects-Interactions (CEI)** pattern is critical. State variables (like `addressMinted[msg.sender] = true`) must be updated *before* any external calls or minting functions are executed.
- **Misconception of "Safe":** The term `safe` in `_safeMint` refers to confirming the recipient can handle the NFT; it does not imply security against malicious actors and actually introduces a reentrancy vector.
## Recommendations
- **Implement Reentrancy Guards:** Use OpenZeppelin’s `nonReentrant` modifier for all public-facing minting functions.
- **Code Audit:** Ensure a third-party audit specifically looks for state updates occurring after external calls.
- **Use `_mint` instead of `_safeMint`:** If the recipient is known or the extra check is not required, `_mint` can be used to avoid the external callback mechanism entirely.