Full Report
In the smart contract code, there is a function that takes in several address for storing an NFT. This includes the deployer (owner) and the beneficiary. When it does the saving, there is no validation that the address of the beneficiary is 0x0. This is rated as a high finding because of the major loss of funds that could occur. This is especially bad since there is no way to change the storage, even as an administrator, to fix this mistake. Should they ALWAYS check that the location being sent to is valid? Hmmm. To me, in the context of this contract, setting beneficiary to the wrong address (not just 0x0), would be bad. I don't understand why only 0x0 is called out. 0x0 address is very special. It is the ERC20/ERC721 specification that the burn function is used to destroy and the mint is used to transfer from the zero address. In this case, they are entirely separate. However, it is not uncommon to see this code shared between other functions. So, with the shared code path and a 0x0 address, this could lead to a burned NFT by accident. Yikes! Overall, simple issue with weird impact. Thanks to bytes032 for all of the fun Solidity challenges lately.
Analysis Summary
# Vulnerability: Missing Zero-Address Validation for Beneficiary in Meebits/Beebots Contract
## CVE Details
- **CVE ID**: N/A (Smart Contract Audit Finding)
- **CVSS Score**: 7.5 (High) - *Estimated based on permanent loss of funds*
- **CWE**: CWE-20 (Improper Input Validation)
## Affected Systems
- **Products**: Redacted (Meebits/Beebots NFT Smart Contract)
- **Versions**: Initial deployment version (Commit `2ec4ce8`)
- **Configurations**: Contracts where the `_beneficiary` address is set exclusively during the constructor/initialization phase without a setter function.
## Vulnerability Description
The smart contract's constructor accepts a `_beneficiary` address parameter, which is designated to receive all proceeds from NFT sales. The contract fails to implement a check to ensure that the provided address is not the zero address (`0x0000000000000000000000000000000000000000`).
In Solidity, if this address is mistakenly set to `0x0` during deployment, all subsequent sale revenue sent to the beneficiary will be permanently lost (burned), as no private key exists for the zero address. The severity is amplified because the contract lacks a function to update the storage of this address after deployment, making the mistake irreversible.
## Exploitation
- **Status**: PoC available (Manual Analysis)
- **Complexity**: Low (The error occurs during deployment/initialization)
- **Attack Vector**: Network (Triggered via interaction with the `mint` or `sale` functions following an incorrect deployment)
## Impact
- **Confidentiality**: None
- **Integrity**: Low (Incorrect state initialization)
- **Availability**: High (Permanent loss of access to sale proceeds/financial assets)
## Remediation
### Patches
- The contract should be redeployed with a corrected constructor that includes a `require` statement.
- Example fix: `require(_beneficiary != address(0), "Invalid beneficiary address");`
### Workarounds
- **Deployment Verification**: Use deployment scripts (Truffle/Hardhat) with built-in validation to ensure parameters are not null or zero.
- **Contract Redeployment**: Since the beneficiary address is immutable after deployment, the only workaround is to abandon the current contract and deploy a new instance before any significant funds are processed.
## Detection
- **Indicators of Compromise**: All ETH/Tokens from NFT sales are sent to `0x0000000000000000000000000000000000000000`.
- **Detection Methods**: Automated static analysis tools (e.g., Slither, Mythril) can detect missing zero-address checks for critical state variables.
## References
- Code423n4 Finding: hxxps://github[.]com/code-423n4/2021-04-meebits-findings/issues/33
- Vulnerable Code Location: hxxps://github[.]com/code-423n4/2021-04-redacted/blob/2ec4ce8e98374be2048126485ad8ddacc2d36d2f/Beebots.sol#L212