Introduction
We express our gratitude to the Binance team for the collaborative engagement that enabled the execution of this Independent Security Assessment.
On February 10th, Binance revealed → a new and improved Proof of Reserves (PoR) verification system that leverages the power of both Merkle Trees and zk-SNARKs which marks a significant upgrade from the previous system that solely relied on plain Merkle Trees.
Document | |
|---|---|
| Name | Independent Security Analysis Report for Binance |
| Audited By | Luciano Ciattaglia ([email protected]) |
| Bartosz Barwikowski ([email protected]) | |
| Yaroslav Bratashchuk ([email protected]) | |
| Sofiane Akermoun ([email protected]) | |
| Website | https://www.binance.com/→ |
| Changelog | 14/02/2023 - Final Report |
| Platform | BNB Chain |
| Language | GO, Python |
| Tags | ZK, PoR, Verifications |
Document
- Name
- Independent Security Analysis Report for Binance
- Audited By
- Luciano Ciattaglia ([email protected])
- Bartosz Barwikowski ([email protected])
- Yaroslav Bratashchuk ([email protected])
- Sofiane Akermoun ([email protected])
- Website
- https://www.binance.com/→
- Changelog
- 14/02/2023 - Final Report
- Platform
- BNB Chain
- Language
- GO, Python
- Tags
- ZK, PoR, Verifications
Review Scope | |
|---|---|
| Repository | https://github.com/binance/zkmerkle-proof-of-solvency→ |
| Commit | c1884aae22cd17af023ac4424b4e6623eb0ea9dd |
Review Scope
- Commit
- c1884aae22cd17af023ac4424b4e6623eb0ea9dd
Audit Summary
System Overview
Introduction
On February 10th, Binance revealed → a new and improved Proof of Reserves (PoR) verification system that leverages the power of both Merkle Trees and zk-SNARKs which marks a significant upgrade from the previous system that solely relied on plain Merkle Trees.
The integration of zk-proofs enhances the system's security by addressing previous vulnerabilities, such as the possibility of negative balances in fake accounts while preserving user privacy during the verification process.
Hacken conducted an independent technical assessment on the recently released verification system and discovered a critical vulnerability that could lead to the creation of fake debt. This issue has been reported and promptly fixed.
Project Summary
In the project we identified 1 critical issue which allows to fake the total debt amount in the zero knowledge proof circuit, 1 medium severity issue and 2 other low severity issues. The critical and medium severity issues have been already fixed. However, any proof generated before those issues were fixed cannot be verified to be valid, as the critical one allowed for the total debt amount to be tampered. Although the proofs may appear to be valid, it is not possible to ensure that they were not modified due to the vulnerability. The other low severity issues are very unlikely to be abused and do not need to be addressed immediately.
The project has 1157 dependencies, all of them with checksum verification. There were found 42 vulnerabilities within all dependencies, with 16 of them having public exploits available. 22 with high severity and 20 with medium. None of the vulnerable functions are currently being used in the project.
It uses a forked version of gnark → made on Sep 2022 for the circuits and Poseidon → with BN254 hash function to hash the user information and the Sparse Merkle Tree (SMT) data structure to store the hashes. The SMT is implemented using the BSMT → library, and its maximum depth is set to be 28, which means that this Proof Of Solvency approach may be used for more than 250M users.
The code quality is clean and organized.
The README.md contains instructions on how to run tools one by one, and motivation behind the circuits is also detailed →.
The Panic → is used for main function error handling, so all the tools crash with a stack trace in case of an error.
The sample user data (balance sheets) is provided in order to test tools manually. There is a way to fetch (probably production) Postgres configuration from the AWS storage if the remotepasswordconfig flag is provided to the tools that use Postgres.
There was a function to generate fake accounts → in the witness service, which was commented out but still left in the code (probably for manual testing purposes). EmptyAccounts are generated in the witness →, and they are used in case the last account's batch size is less than 864.
The git history log has been modified several times, and as a result, the git metadata is mixed in some places.
References
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-5327 | TotalDebt manipulation vulnerability caused by overflow of BasePrice | fixed | Critical | |
| F-2024-5330 | TotalDebt value underflow caused by integer overflow | fixed | Medium | |
| F-2024-5358 | Merkle Root hash integrity | accepted | Low | |
| F-2024-5357 | Potential omission of users | accepted | Low | |
| F-2024-5360 | Vulnerabilities in dependencies | fixed | Observation | |
| F-2024-5359 | Total amount of users inference | accepted | Observation |
Uncover findings like these to secure your project.
Appendix 1. Severity Definitions
When performing security audits, Hacken is using a risk-based approach that considers Likelihood and Impact metrics to evaluate findings and score severities.
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/binance/zkmerkle-proof-of-solvency→ |
| Commit | c1884aae22cd17af023ac4424b4e6623eb0ea9dd |
| Whitepaper | https://www.binance.com/en/blog/ecosystem/how-zksnarks-improve-binances-proof-of-reserves-system-6654580406550811626→ |
| Requirements | |
| Technical Requirements | https://gusty-radon-13b.notion.site/Proof-of-solvency-61414c3f7c1e46c5baec32b9491b2b3d→ |
Scope Details
- Commit
- c1884aae22cd17af023ac4424b4e6623eb0ea9dd
- Requirements
- Technical Requirements
- https://gusty-radon-13b.notion.site/Proof-of-solvency-61414c3f7c1e46c5baec32b9491b2b3d→