Dipper Network launches million-level DIP bug bounty program
The development of Dipper Network is nearing completion. TestNet 4.0 is now online and the bug bounty program is launched (time period: September 25, 2020-October 15, 2020). The specific details include the following:
0. Related Resources
1) GitHub address:
2) Testnet release version:
3) Official development documents:
4) Smart contract module documentation:
5) Test method: Join testnet V4.0 or deploy private chain.
*Note: The testnet currently only supports solidity contracts. You can use Remix IDE to compile contracts and deploy tests according to the development documentation.
- Business scope
Dipper Network testnet-v4.0.0 code (URL: https://github.com/Dipper-Labs/Dipper-Protocol/releases)
*Main types of vulnerabilities: system bugs, overflow vulnerabilities, smart contract module vulnerabilities, transfer, mortgage, de-mortgage and other operational bugs, memory leaks, endless loops, DDoS attacks, abnormal exits, consensus failures, system startup failures, etc. and all other threats Bugs and vulnerabilities in the safe operation of blockchain networks.
2. Processing flow
2.1 Reporting stage
The reporter visits the Github page of the project party (URL: https://github.com/Dipper-Labs/Dipper-Protocol/issues) to submit threat intelligence (status: pending, need to indicate the reproduction method and attach the relevant code).
2.2 Processing stage
Within three working days, the Dipper Labs team handled the problem, made a conclusion and scored (status: confirmed / ignored). If necessary, we will communicate with the reporter for confirmation, and ask the reporter for assistance.
2.3 Repair phase
1) The Dipper Labs team solves the problem and arranges for the update to go online (status: fixed). The repair time depends on the severity of the problem and the difficulty of repairing. Generally speaking, serious and high-risk problems are within 24 hours, medium-risk problems are within 3 working days, and low-risk problems are within 7 working days;
2) The reporter rechecks whether the security problem is repaired (status: rechecked / rechecked objection);
3) After the reporter confirms that the security problem has been fixed, the Dipper Labs team informs the processing conclusion and vulnerability score, and awards it (status: closed)
2.4 Reward criteria
The final reward depends on the severity of the vulnerability and the actual impact of the vulnerability. The values in the table are the highest rewards of each level;
The related vulnerabilities of the Cosmos SDK will be dealt with separately.
3. Vulnerability classification details
3.1 Serious vulnerabilities
Serious vulnerabilities refer to those that occur in the core system business system (core control system, domain control, business distribution system, fortress and other control systems that can manage a large number of systems), which can cause a large area of impact, and obtain a large number (as appropriate based on actual conditions) Limited) Business system control authority, access to core system management personnel authority and control of the core system.
including but not limited to:
1) Control of multiple machines in the intranet
2) The core back-end super administrator obtains the authority and causes a large-scale enterprise core data leakage, which can have a huge impact
3) Smart contract overflow and conditional competition loopholes
3.2 High-risk vulnerabilities
1) System access (getshell, command execution, etc.)
2) SQL injection of the system (back-end vulnerabilities are downgraded, packaged and submitted as appropriate)
3) Unauthorized access to sensitive information. Including but not limited to bypassing authentication and directly accessing the management background, important background weak passwords, and SSRF for obtaining large amounts of sensitive information on the intranet, etc.)
4) Read any file
5) XXE vulnerability that can obtain arbitrary information
6) Ultra-authoritative operations involving money, bypassing payment logic (need to be used successfully)
7) Serious logic design defects and process defects. Including but not limited to any user login vulnerabilities, batch modification of arbitrary account password vulnerabilities, logic vulnerabilities involving enterprise core business, etc., except for verification code blasting
8) Other vulnerabilities that affect users on a large scale. Including, but not limited to, stored XSS that can be automatically propagated on important pages, stored XSS that can obtain management member authentication information and successfully use, etc.
9) A large number of source code leaks
10) Defects of smart contract authority control
3.3 Medium-Dangerous Vulnerabilities
1) Vulnerabilities that require interaction to affect users. Including but not limited to storage XSS for general pages, CSRF involving core business, etc.
2) Ordinary unauthorized operation. Including but not limited to bypassing restrictions, modifying user information, performing user operations, etc.
3) Denial of service vulnerability. Including but not limited to remote denial of service vulnerabilities that cause website application denial of service, etc.
4) Vulnerabilities caused by successful blasting of sensitive system operations such as arbitrary account login and arbitrary password retrieval due to verification code logic
5) The sensitive authentication key information stored locally is leaked, and it needs to be effectively used
3.4 Low-risk vulnerabilities
1) Local denial of service vulnerability. Including, but not limited to, local denial of service on the client side (parse file format, crash caused by network protocol), problems caused by the exposure of Android component permissions, and common application permissions, etc.
2) General information leakage. Including but not limited to Web path traversal, system path traversal, directory browsing, etc.
3) Reflective XSS (including DOM XSS / Flash XSS)
4) Ordinary CSRF
5) URL jump vulnerability
6) SMS bombs, mail bombs (each system only accepts one vulnerability of this type)
7) Other vulnerabilities that are less harmful and cannot be proved to be harmful (such as CORS vulnerabilities for which sensitive information cannot be obtained)
8) SSRF with no echo and no in-depth use of successful SSRF
3.5 Types of vulnerabilities not currently charged
1) SPF mail forgery vulnerability
2) Interface brute force blasting of registered user name vulnerabilities
4) CSRF issues for non-sensitive operations
5) Separate Android APP
android:allowBackup=”true” issues, local denial of service issues, etc. (except for in-depth exploitation)
6) Problems such as slow request caused by modifying the image size
7) Leakage of Nginx/Tomcat and other versions
8) Some functional bugs can not cause security risks
3.6 Prohibited behavior
1) Social work and phishing behaviors to personnel are prohibited;
2) The loophole prohibits external communication;
3) Testing vulnerabilities are only for proof testing, and destructive testing is strictly prohibited. If harm is caused inadvertently, it should be reported in time. At the same time, sensitive operations performed during testing, such as deletion, modification, etc., should be explained in the report;
4) It is forbidden to use scanners for large-scale scanning. If the business system or network is unavailable, it will be handled according to relevant laws;
5) Test vulnerabilities should try to avoid directly modifying the page, repeating the pop-up box (log is recommended for xss verification), stealing cookies, obtaining other user information and other offensive payloads (if you are testing blind typing, please use dnslog); If you accidentally use a more aggressive payload, please delete it in time, otherwise we have the right to pursue relevant legal liabilities.
I have referred to the Prophet Vulnerability Grading Standard, and I would like to express my gratitude.