Huami Security Emergency Response Center
1、SRC Responsibilities

Huami Security Emergency Response Center (https://src.zepp.com), referred to as "ZSRC", is Huami's commitment to maintaining a healthy and safe Internet environment, ensuring the security of Huami's products and business lines, and promoting cooperation with the industry and the The company cooperates and communicates closely while establishing a platform for vulnerability collection and emergency response. Users are very welcome to report the security vulnerabilities of Huami products and services to us, and work with us to ensure the safe online life of many users at home and abroad

2、Huami business and SRC communication

(1)Huami's business scope: *.huami.com, *.amazfit.com, *.zepp.com and other Huami domain names. Products include: Zepp, Midong Health, Zepp life, WeChat applet, etc.

(2)Huami SRC Designated Receiving Vulnerabilities and Communication Channels:sec@zepp.com

3、SRC Disposal Process

(1)Within one business day after the vulnerability is submitted, SRC staff will confirm the received vulnerability report and begin to assess the problem;

(2)Within three working days after the vulnerability is submitted, the SRC staff will deal with the vulnerability problem, draw a conclusion and count it into the contribution value (if necessary, it will communicate with the reporter to confirm, please provide the reporter for assistance);

(3)The business department fixes the vulnerabilities reported in the report and arranges the update to go online; the repair time depends on the severity of the vulnerability and the difficulty of repair. Generally speaking:

Serious bugs will be fixed within 1 working day;

High-risk vulnerabilities will be fixed within 3-5 working days;

Moderate vulnerability fixes within 15 working days;

Low-risk vulnerabilities will be fixed or ignored within 30 working days;

Client security issues are limited by version release, and the repair time is determined according to the actual situation;

(4)Vulnerability reporters can review whether the security issues are successfully repaired. If they find that the fixed vulnerabilities can still be exploited, they can contact the processing personnel, and the platform will add additional rewards。

4、SRC Vulnerability Rating Rules

4.1、Serious

(1)A vulnerability that directly obtains core system permissions. Including but not limited to remote arbitrary command execution, code execution, uploading webshell, SQL injection to obtain system permissions, etc.。

(2)Serious leakage of sensitive information. Including but not limited to SQL injection of core DB, access to identity information of a large number of core users, personal sensitive data, logical loopholes in business order information, etc.。

(3)Logic flaws that directly lead to serious impacts. Including but not limited to logic loopholes in payment modules, forged core application accounts, and loopholes in arbitrary account password changes, etc。

4.2、High Risk

(1)A vulnerability that directly obtains general system permissions. Including but not limited to remote arbitrary command execution, code execution, uploading webshell, SQL injection to obtain system permissions, buffer overflow, etc。

(2)Important unauthorized access operations, including but not limited to bypassing authentication to directly access management background operations containing sensitive information, unauthorized access to important services containing sensitive information, weak passwords in the background of important services with actual operation authority in the business, additions, deletions, modifications and inspections More important ultra vires such as arbitrary user information, SSRF that can directly obtain a large amount of sensitive information on the intranet (do not scan the intranet)。

(3)Business logic loopholes in important activities, loopholes that can directly obtain higher benefits or can bring a lot of economic losses to the company through loopholes。

4.3、Medium Risk

(1)Vulnerability that requires interaction to obtain user identity information. Including but not limited to stored XSS, CSRF for important and sensitive operations of core business。

(2)Ordinary unauthorized operation. Including but not limited to unauthorized operations that can query other small amounts of user data。

(3)General information leakage. Including but not limited to Github involving internal systems, email password disclosure。

(4)Local arbitrary code execution. Including but not limited to locally exploitable stack overflow, format string, local privilege escalation, file-associated DLL hijacking, and native code execution vulnerabilities caused by other logic issues。

4.4、Low Risk

(1)Vulnerability of obtaining user identity information only in specific non-popular browser environments (such as browsers smaller than IE11, etc.). Including but not limited to stored XSS, reflected XSS, DOM-XSS, etc。

(2)Minor information leakage vulnerability. Including but not limited to non-sensitive system source code and password leaked by Github, SVN file leak, phpinfo, logcat sensitive information leak。

(3)Local denial-of-service vulnerabilities that affect the normal usage scenarios of PC clients and mobile clients. Including but not limited to local denial of service vulnerabilities caused by component permissions。

(4)URL jump. Including but not limited to URL redirection vulnerabilities under subdomains defined within Huami's business scope, which need to be proven to be redirected directly。

(5)SSRF vulnerabilities that can directly access the intranet but have no echo。

(6)It is difficult to use but there may be potential safety hazards. Including but not limited to CSRF that may cause propagation and exploitation, and remote code execution vulnerabilities that require man-in-the-middle attacks, and provide a valid PoC。

(7)Bombing of high-frequency and unlimited text messages for any designated user or mobile phone number。

4.5、Invalid (no immediate security issue/unable to directly exploit/unable to prove the existence of the vulnerability/exploitable vulnerability)

(1)Unrelated security bugs. Including but not limited to garbled webpages, webpages that cannot be opened, and certain functions that cannot be used。

(2)Unexploitable "loopholes". Including but not limited to meaningless scanner vulnerability reports, Self-XSS that can only bounce itself, etc.。

(3)Undocumented guesswork or unreproducible vulnerability。

(4)Non-Huami Business。

(5)Other vulnerabilities considered negligible。

5、SRC Rewards Program

SRC reward standard (not distribute cash directly)

Serial number Vulnerability level Bug Bounty Criteria(USD) Remark
1 Serious 150 - 300 (USD) Huami product portfolio, based on vulnerability value assessment
2 High risk 100 - 150 (USD) A single Huami product
3 Medium risk 20 - 100 (USD) A single Huami product
4 Low risk Written thanks /
5 Invalid None /

Reward distribution mechanism:

After reviewing the vulnerability submitted by the white hat, the vulnerability auditor will assign the corresponding reward to the vulnerability according to the rating standard, which will take effect after confirming with the white hat.。

After confirming the relevant rewards and personal information with the white hat, the vulnerability auditor will arrange for the distribution of corresponding rewards. The actual arrival time of the rewards is subject to the actual local situation. If there is any problem with the reward distribution, please contact us in time to confirm。

6、Precautions

(1)The reward standard is only for threat intelligence that affects Huami products and business。

(2)The right to interpret the processing procedures and grading rules belongs to Huami. We have the right to adjust the processing procedures and grading rules and re-announce them according to the situation;

(3)White hats are not allowed to disclose vulnerability details on any public channels or self-media (such as Weibo, forums, communities, official accounts, Moments, Facebook, twitter, instagram, etc.)

(4)Multiple vulnerabilities generated by the same vulnerability source are generally counted as one vulnerability, and the same vulnerability only counts contributions to the earliest submitter; those submitted on other platforms are not counted as contributions; those submitted to the outside world that have already been disclosed are not included; Known vulnerabilities do not double-calculate the contribution value;

(5)The final contribution value of each level of vulnerability is determined by comprehensive factors such as the difficulty of exploiting the vulnerability and the scope of influence. If the vulnerability triggering conditions are very harsh, the vulnerability level can be reduced;

(6)It is strictly forbidden to use automated missed scans or auxiliary tools to initiate high-frequency scans. The test results should only be used to prove that the vulnerability exists and can be exploited (ie POC). It is strictly forbidden to use the vulnerability for illegal operations, including but not limited to: dragging the library, intranet penetration etc;

(7)Do not use security testing as an excuse to use intelligence information to damage user interests, affect normal business operations, disclose before repair, steal user data, etc., will not count, and reserves the right to take further legal actions.

If you have any questions, you can send feedback through Huami email sec@zepp.com