Scope of Business

Includes all the code in the codebase: https://github.com/Qtumproject/Qtum

Processing Flow

Reporting Stage

The reporter visits "SlowMist Zone" website and goes to "Submit Bug Bounty" (URL：https://slowmist.io/en/bug-bounty.html) to submit a threat intelligence. (Status: pending review)

Processing Stage

1. Within one working day, the SlowMist Security Team will confirm the threat intelligence report from the "SlowMist Zone", follow up, evaluate the problem, and feed the intelligence back to the Qtum contact person in the meantime (status: under review).

2. Within three working days, the Qtum technical team will deal with the problem, draw conclusions and record points (status: confirmed / ignored). They will communicate with the reporter if necessary, and ask the reporter for assistance.

Repairing Stage

1. The Qtum business department shall repair the security problems in the threat intelligence and update online (status: repaired). The repairing timeframe depends on the problem severity and the repair difficulty. Generally speaking, it is within 24 hours for the critical and high-risk problems, within 3 working days for the medium-risk problems, and within 7 working days for the low-risk problems. The App security issue is limited by the version release, and the repairing timeframe is on a case-by-case basis.

2. The reporter will review whether the security problem has been repaired (Status: reviewed/reviewed with objection).

3. After the reporter confirms that the security problem is repaired, the Qtum technical team will inform the SlowMist Security Team of the conclusion and the vulnerability score. They will issue rewards with the SlowMist Security Team (status: completed).

Vulnerability Level and Reward Standards

Level	Qtum Reward		SlowMist Zone Reward*
	Submit and solve problems	Submit a question only
Critical	$10,000	$2,000	512 SLOWMIST
High	$5,000	$1,000	256 SLOWMIST
Medium	$2,500	$600	100 SLOWMIST
Low	$1,200	$300	32 SLOWMIST
Improvement	$600	$200	32 SLOWMIST

*SLOWMIST is Ethereum ERC20 Token, the ecological incentive token for the SlowMist Zone.

*Note: in US dollars. The final release will be in the form of equal value BTC, please fill in the bitcoin address when submitting the vulnerability.

1. For issues that have been reported on Bitcoin, Ethereum, etc., the bounty will be discounted accordingly.

2. The values in the table are the highest rewards for each level, and the specific award amount will be determined by the Qtum security team. For the issuance of rewards, we will also refer to several of them for review. If you only submit the vulnerability, only need to focus on the materials submitted.

Notice:

1. If there is already a similar issue or the Qtum team already knows and is working on the issue, it will not apply to the bounty plan.

2. There will be no bounty if the problem is made public and causes harm before it is resolved.

3. When repairing, please fork the code to your own repository for repair, and then submit the pull request to merge into master branch after the Qtum member review.

4. Qtum team members are employed by the Qtum Foundation, and Qtum members will not receive a bounty if they participate in bug fixes directly or indirectly.

5. The bounty program to solve the Qatum core product technology to enhance product robustness. Qtum websites, forums, organizational structures, etc. are not included in the bounty program.

6. The award of the bounty plan is related to many factors, such as workload, influence scope, severity, etc. The specific amount of the bounty plan is subject to the conclusion of Qtum security team.

Submitted materials (25%):

Complete the report materials.

Code fixes (50%):

Code fixes are completed without introducing new problems, if there are new problems were introduced, they need to be resolved in the same commit.

If you don't do the code fix, just provide the repair suggestions, the bounty will be discounted.

Automated test script coverage or manual test method specification (25%)

Automated test scripts play an extremely important role in continuous integration of code and quality control under rapid iteration, so the improvement of automated test scripts will be an important assessment indicator:

• Provide automated test script coverage: 100%
• Provide manual test method specification: 60%

Critical Vulnerabilities

A critical vulnerability refers to the vulnerability occurs in the core business system (the core control system, field control, business distribution system, fortress machine and other control systems that can manage a large number of systems). It can cause a severe impact, gain business system control access (depending on the actual situation), gain core system management staff access, and even control the core system.

Including but not limited to:

• Multiple devices access in the internal network.
• Gain core backend super administrator access, leak enterprise core data and cause a severe impact.
• Smart contract overflows, conditional competition vulnerability, etc. can cause serious data problems on the mainnet.
• Consensus layer vulnerability or attacks serious DDos on the mainnet at a small cost, directly result in the mainnet to crash or fail to pop out of the block.
• Due to problems such as node overflow and command execution, node server is invaded, and suffered from data leakage, system file reading, command execution and other hazards.
• Attacks due to defects in the consensus mechanism, such as available sybil attack, double spend, etc.

High-risk Vulnerabilities

• Gain system access (getshell, command execution, etc.).
• System SQL injection (backend vulnerability degradation, prioritization of package submission as appropriate).
• Gain unauthorized access to the sensitive information, including but not limited to, the direct access to the management background by bypassing authentication, brute force attackable backend passwords, and to obtain SSRF of sensitive information in the internal network, etc.).
• Arbitrarily document reading.
• XXE vulnerability that can access any information.
• Unauthorized operation that involves money, payment logic bypassing (need to be successfully utilized).
• Serious logical design defects and process defects. This includes but is not limited to any user log-in vulnerability, the vulnerability of batch account password modification, logic vulnerability involving enterprise core business, etc., except for verification code explosion.
• Other vulnerabilities that affect users on a large scale. This includes but is not limited to the storage XSS that can be automatically propagated on the important pages, and the storage XSS that can access administrator authentication information and can be successfully utilized.
• Leakage of a lot of source code.
• Consensus layer message is mishandled and a few number of nodes affect.
• Obtain control rights through a full-node P2P network intrusion server.
• Excepions smart contract attacks to avoid exhausting node resources.
• Error implementation or use of encryption algorithms, including encryption, decryption, signature, verification, etc.

Medium-risk Vulnerabilities

• The vulnerability that can affect users by the interaction part. It includes but is not limited to the storage XSS on general pages, CSRF involving core business, etc.
• General unauthorized operation. Including but not limited to modify user data and perform user operation by bypassing restrictions.
• The vulnerabilities caused by a successful explosion with the system sensitive operation, such as any account login and password access, etc. due to verification code logic defects.
• The leakage of locally-stored sensitive authentication key information, which needs to be able to use effectively.
• The design of the main chain business is flawed, which prevents the business from being implemented properly.
• RPC interface or transactions are unreasonable in parameter processing, leading to more serious problems, such as SQL injection of the system.
• Restricted denial-of-service vulnerability. Under certain restrictions, it may cause the remote denial-of-service vulnerabilities caused by denial-of-service of applications

Low-risk Vulnerabilities

• Local denial-of-service vulnerabilities. Including but not limited to the client local denial-of-service (parsing file formats, crashes generated by network protocols), problems that are caused by Android component permission exposure, general application access, etc.
• General information leakage. This includes but is not limited to Web path traversal, system path traversal, directory browsing, etc.
• Reflective type XSS (including DOM XSS/Flash XSS)
• URL skip vulnerability
• SMS bombs, mail bombs (each system only accepts one type of this vulnerability).
• Other vulnerabilities that are less harmful and cannot be proven to be harmful (such as CORS vulnerability that cannot access sensitive information).
• No return value and no in-depth utilization of successful SSRF.
• RPC interface return value or some data structure design is unreasonable and affect the user experience, need to point out the unreasonable place.
• Some critical user experience issues
• Other vulnerabilities that are less harmful and cannot be proven to be harmful.

Vulnerabilities that are not accepted at the moment (even if such a vulnerability is submitted, it will be ignored)

• Email Spoofing / Missing SPF Record.
• User enumeration vulnerability.
• Self-XSS
• CSRF issues for non-sensitive operations.
• A separate issue about Android app android:allowBackup=”true” , and the service is denied locally, etc. (unless in-depth use).
• Some problems such as changing the size of the image and causing slow requests, etc.
• Version leak issues such as Nginx/Tomcat, etc.
• Some functional bugs that do not pose a security risk issue.

Prohibited behaviors

• It is forbidden to conduct social engineering and phishing to people;
• It is forbidden to leak the details of the vulnerability;
• Vulnerability testings are only limited to PoC(proof of concept), and destructive testings are strictly prohibited. If harms are caused inadvertently during the testing, it should be reported in time. Meanwhile, sensitive operations performed in the test, such as deletion, modification, and other operations, are required to be explained in the report;
• It is forbidden to use a scanner for large-scale scanning. If the business system or network becomes unavailable, it will be handled according to relevant laws;
• Those who test the vulnerability should try to avoid modifying the page directly, continuing poping up the message box (dnslog is recommended for xss verification), stealing cookies, and obtaining aggressive payload such as the user information (for blind xss testing, please use dnslog). If you accidentally used a more aggressive payload, please delete it in time. Otherwise, we have the right to pursue related legal liabilities.

Special thanks to The xianzhi vulnerability classification criteria referred here.