Full Report
SPARKN is a web3 protocol for people to post a problem where somebody can come up with a solution for them. This is really generally but the intent of the protocol. The ProxyFactory contract serves as a gateway for users to interact with the contests. In particular, a proxy can be made for each contest to distribute rewards to its winners. Within the ProxyFactory there is a function called getProxyAddress(). Given a salt and implementation address, it will return the address that the proxy will be deployed to. This is because users are expected to send funds prior to the proxy deployment to this address. The vulnerability is that there is no validation that the implementation and salt will actually be correct. As a result, if they called this with bad parameters, then the funds would be sent to the wrong location, being lost forever. This was reported as a medium severity finding. Bad user functionality as finding is so weird to me. As a developer, I expect my users to interact with the protocol the proper way. If they mess up, I treat this as an issue on their end. I don't agree with these types of findings. However, it does feel like easy money on contests so I'm not going to complain too loudly.
Analysis Summary
# Vulnerability: Unvalidated Deterministic Address Calculation in SparkN ProxyFactory
## CVE Details
- **CVE ID**: Not Assigned (Protocol-specific audit finding)
- **CVSS Score**: Medium (Vendor/Audit classification)
- **CWE**: CWE-20: Improper Input Validation
## Affected Systems
- **Products**: SPARKN Web3 Protocol
- **Versions**: Initial Audit Version (SparkN Audit Contest)
- **Configurations**: `ProxyFactory` contract deployments utilizing `getProxyAddress()` for pre-funding contests.
## Vulnerability Description
The `ProxyFactory` contract includes a view function `getProxyAddress(bytes32 salt, address implementation)` designed to calculate the deterministic address where a proxy will be deployed using `CREATE2` logic.
The protocol's workflow expects users (organizers) to call this function to determine the future address of a contest and send reward funds to it *before* the actual deployment transaction is executed. However, the function lacks any validation for the `salt` and `implementation` parameters. If a user provides an incorrect implementation address or an invalid salt, the function returns a valid-looking Ethereum address that does not correspond to a valid future deployment.
## Exploitation
- **Status**: PoC available (Identified during Audit Contest)
- **Complexity**: Low (Triggered by user error/input mistakes)
- **Attack Vector**: Network (Interaction with Smart Contract)
## Impact
- **Confidentiality**: None
- **Integrity**: Low (Incorrect state expectation)
- **Availability**: Medium/High (Permanent loss of funds; tokens sent to un-deployable addresses are unrecoverable)
## Remediation
### Patches
- The protocol developers have been advised to implement internal checks to ensure provided parameters match registered contest data.
### Workarounds
- **Frontend Validation**: Interaction layers (dApps) should strictly validate that the `implementation` address being passed matches the official protocol implementation before displaying the proxy address to users.
- **Double-Check Parameters**: Users must manually verify that the salt and implementation address match the official contest requirements.
## Detection
- **Indicators of Compromise**: High volumes of assets sent to addresses that remain empty (no contract code) long after a contest should have been deployed.
- **Detection Methods**: Specialized blockchain indexers can be used to compare `getProxyAddress` calls against successful `deployProxyAndDistribute` events to identify "ghost" addresses that received funds but were never deployed.
## References
- Johnny Time Audit Summary: hxxps[://]medium[.]com/post-page/a-medium-smart-contract-vulnerability-in-audit-contest-simple-explained-16bfef99b833
- SparkN Protocol Documentation: hxxps[://]github[.]com/code-423n4/2023-08-sparkn (Reference for contest codebase)