Scope of Business
MYKEY App and corresponding server, https://github.com/mykeylab/MYKEY-APP/releases
EOS Smart Contract:
NEW ETH Smart Contract，Source Code：https://github.com/mykeylab/keyid-eth-contracts
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)
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 MYKEY contact person in the meantime (status: under review).
2. Within three working days, the MYKEY 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.
1. The MYKEY 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
3. After the reporter confirms that the security problem is repaired, the MYKEY 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
||MYKEY Reward NEW
||SlowMist Zone Reward*
*Remark: the final award depends on the severity of the vulnerability and the true impact of the vulnerability, the values in the table are the highest rewards for each level.
*SLOWMIST is Ethereum ERC20 Token, the ecological incentive token for the SlowMist Zone.
A critical vulnerability refers to the vulnerability occurs in the core business system. 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. At the chain level, obtain full control of the contract, happens at the blockchain level, which can get fully control of the contract is obtained.
Including but not limited to:
- Multiple devices access in the internal network.
- Gain core backend super administrator access, enterprise core data leakage and cause a severe impact.
- Change the owner of contract,by pass the logic of contract and execute the operation out of expected, causing significant loss of property.
- 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.
- 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.
- A denial of service attack caused by an interface design.
- The MITM attack causes the content of the transaction to be altered, resulting in actual losses.
- The permission control defects in the smart contract.
- Smart contract overflow, conditional competition vulnerability, logical vulnerability and transaction replay vulnerability.
- Smart contract resource control vulnerabilities lead to unlimited resource consumption.
- The deferred action of the smart contract was not carried out as scheduled, causing actual impact.
- Sensitive authentication key information stored locally leakage, and it needs to be used effectively.
- The vulnerability that can affect users by the interaction part. Including but not limited to the storage XSS on general pages, CSRF involving core business, etc.
- Denial-of-service vulnerabilities. Including but not limited to the remote denial-of-service vulnerabilities caused by denial-of-service of web applications, blockchain resource exhaustion denial-of-service.
- Bypass user login verification, read user sensitive information, or modify user related information.
- 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.
- 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)
- General CSRF
- URL skip vulnerability
- Other vulnerabilities that are less harmful and cannot be proven to be harmful (such as CORS vulnerability that cannot access sensitive information).
- Email Spoofing / Missing SPF Record.
Vulnerabilities that are not accepted at the moment (even if such a vulnerability is submitted, it will be ignored)
- User enumeration vulnerability.
- 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.
- 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.