Scope of Business
1. Ontology Blockchain (GitHub:https://github.com/ontio)
2. Ontology Wallets
The reporter visits "SlowMist Zone" website and goes to "Submit Bug Bounty" (URL：https://slowmist.io/en/bug-bounty.html) to submit a vulnerability report (Status: Under Review).
1. Within 1 working day, the SlowMist Security Team will confirm the vulnerability report from the "SlowMist Zone", follow up, evaluate the problem, and send the threat intelligence back to the Ontology contact person (Status: Under Review).
2. Within 3-10 working days, the Ontology technical team will address the bug, draw conclusions and record points (Status: Confirmed/Ignored). They will communicate with the reporter if necessary, and ask the reporter for assistance.
1. The Ontology team shall fix the security bugs identified by the vulnerability report and provide updates online (Status: Fixed). The fixing time frame depends on the bug’s severity and the repair difficulty. Generally speaking, it is within 24 hours for critical and high risk bugs, within 3 working days for medium risk bugs, and within 7 working days for low risk bugs. The app security issue is limited by the version release, and the repairing timeframe is determined on a case-by-case basis.
2. The reporter will review whether the security bug has been fixed (Status: Reviewed/Reviewed With Objection).
3. After the reporter confirms that the security bug is fixed, the Ontology technical team will inform the SlowMist Security Team of the conclusion and the vulnerability score. They will issue rewards to the SlowMist Security Team (Status: Completed).
Vulnerability Level and Reward Standards
||SlowMist Zone Reward*
||$12000 equivalent ONG
*Remark: The final award depends on the severity and true impact of the vulnerability. The values in the table are the highest rewards for each level. Critical vulnerabilities reward will be in the form of ONG at the price of ONG/USDT the day before the issue.
*SLOWMIST is the integral of the SlowMist Zone.
A critical vulnerability refers to a vulnerability that 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 situation), gain core system management staff access, and even control the core system.
Critical vulnerabilities include but are not limited to:
- Smart contract overflows, conditional competition loopholes, etc. will cause serious data problems on the MainNet
- Arbitrary command execution on node host
- Destruction of data consistency across the network
- Transaction, block or consensus message signature forgery, replay or valid data tampering
- Access control flaws
- Private key disclosure or unauthorized call to signed API
- Large amounts of additional issuance or overspending of assets, large amounts of theft or excessive spending
- The entire network crashes, no response or consensus is stalled, and legal transactions cannot be executed
High Risk Vulnerabilities
High risk vulnerabilities include but are not limited to:
- Involving the unauthorized operation of the token, bypassing the payment logic (required to be successfully used)
- The permission control defects in the smart contract
- Node host crashes or becomes unresponsive
- Node program crashes or becomes unresponsive, unable to receive, process, and forward legal transactions or blocks
- Large losses or freezing of other people’s assets
- Leakage of sensitive information, such as unauthorized access to private data, decipherable cipher text, etc.
Medium Risk Vulnerabilities
Medium risk vulnerabilities include but are not limited to:
- The leakage of locally-stored sensitive authentication key information, which needs to be able to be used effectively
- Invalid transaction, block or consensus message data tampering
- Small additional issuance or overspending of assets, theft or excessive spending
- Small loss or freezing of other people’s assets
- RPC service crashes or becomes unresponsive
Low Risk Vulnerabilities
Low risk vulnerabilities include but are not limited to:
- Local denial-of-service vulnerabilities. It includes but is 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.
- Node response has dropped significantly
- Significantly reduce the difficulty of other attacks
- Other vulnerabilities that are less harmful and cannot be proven to be harmful (such as CORS vulnerability that cannot access sensitive information)
Vulnerabilities That Are Not Accepted (even if such a vulnerability is submitted, it will be ignored)
- SPF mail forgery vulnerability
- Interface brute force blasting of registered username vulnerabilities
- 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 slow requests caused by changing the size of the image etc.
- Version leak issues such as Nginx/Tomcat, etc.
- Some functional bugs that do not pose a security risk issue
- It is forbidden to conduct social engineering and phishing
- It is forbidden to leak the details of the vulnerability
- Vulnerability tests are limited to PoC (proof of concept), and destructive tests are strictly prohibited. If harms are caused inadvertently during testing, they should be reported immediately. Meanwhile, sensitive operations performed in a 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 popping 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 immediately. Otherwise, we have the right to pursue related legal action
Special thanks to the xianzhi and cnvd vulnerability classification criteria referred to here.