Bitget External Threat Intelligence Processing Standard

Dear Bitget users:

Please read the Bitget External Threat Intelligenence Processing Standard carefully.

Scope of Application

This process applies to all intelligence received by the Bitget Security Response Center (security@bitget.com).

Implementation Date

This document has been implemented as of the date of publication.

Basic Principle

1. Bitget attaches great importance to the security of its products and services. We promise that all the feedbacks from each reporter will be followed up, analyzed and processed, and promptly responded.

2. Bitget supports responsible vulnerability disclosure and processing. We promise that we will give thanks and feedback to every user who guards the spirit of white hat, protects the interests of users and helps Bitget improve safety and quality.

3. Bitget opposes and denounces all hacking behaviors that use vulnerability testing as an excuse to exploit security vulnerabilities to damage or harm users, including but not limited to exploiting vulnerabilities to steal user privacy and virtual property, invading business systems, stealing user data, and maliciously exploiting vulnerabilities, etc. .

4. Bitget opposes and condemns all use of security loopholes to intimidate users and attack competitors.

5. Bitget believes that the handling of each security vulnerability and the progress of the entire security industry are inseparable from the cooperation of all parties. It is hoped that enterprises, security companies, security organizations, and security researchers will join the process of “responsible vulnerability disclosure” to work together to build a safe and healthy Internet.

Threat Intelligence Feedback and Processing

[Reporting Stage]

Threat intelligence reporters feed back threat intelligence through the Bitget threat intelligence receiving mailbox (security@bitget.com).

[Processing Stage]

1. Within one working day, the Bitget Security Emergency Response Center (BGSRC) staff will confirm the threat intelligence report received and follow up to begin the assessment of the problem (status: review).

2. Within three working days, the BGSRC staff handles the problem, gives a conclusion and scores (status: confirmed/ignored). When necessary, the BGSRC staff will communicate with the reporter to confirm and ask the reporter to assist.

[Repair Stage]

1. The business unit fixes the security issues in the threat intelligence and schedules the update to go live (status: fixed). The repair time depends on the severity of the problem and the difficulty of repair. Generally speaking, serious and high-risk problems within 24 hours, medium risk within three working days, low-risk within seven working days. Client security issues are limited by version release, and repair time is determined based on actual conditions.

2. The threat intelligence reporter reviews whether the security issue is fixed (status: reviewed/reviewed objection).

[Completion stage]

1. BGSRC will issue the last month's threat intelligence processing announcement in the first week of each month. The threat intelligence reporters in the previous month will thank and announce the handling situation; the critical or major impact threat information will issue an emergency security announcement separately.

2. Threat intelligence reporters can use points to redeem security coins for replacement of cash or platform token. After the replacement is completed, BGSRC will reward threat intelligence reporters; and occasionally there will be rewards and meeting activities.

Threat Intelligence Scoring Standard

Bitget threat intelligence mainly contains: vulnerabilities and security intelligence of Bitget's business. Below we will describe their scoring criteria separately.

Business Vulnerability Scoring Standard

According to the degree of vulnerability, it is divided into five levels: severe, high, medium, low and no. The rating of each level is as follows:

[Severe]

The score range is 9-10, and the security coin range is 1080~1200.

This level includes:

1. Direct access to vulnerability (server permissions, important product client permissions). Includes, but is not limited to remote arbitrary command execution, uploading webshell, exploitable remote buffer overflow, available ActiveX stack overflow, available browser "use after free" vulnerabilities, exploitable exploits with remote kernel code, and other exploitable remote code execution vulnerabilities caused by logical problems.

2. A vulnerability that directly leads to a serious information disclosure. Includes, but is not limited to, SQL injection vulnerabilities for important DBs.

3. A logical vulnerability that directly causes serious impact. Includes, but is not limited to forging arbitrary ID to send message vulnerabilities, forging any ID bomb to any TIPS to any user vulnerability, any account password change vulnerability.

[High]

Score range 6-8, security coin range 360~480 (exchange security coin coefficient: Web/server 60; PC c/mobile terminal 60)

This level includes:

1. A vulnerability that can directly steal user identity information. Including: storage XSS vulnerabilities on key pages of important services (such as Bitget master), SQL injection vulnerabilities in common sites.

2. Overstep access. Includes, but is not limited to, sensitive management background logins.

3. High-risk information disclosure vulnerabilities. Includes, but is not limited to, sensitive data leaks that are directly usable.

4. Local arbitrary code execution. Includes, but is not limited to, locally available stack overflow, UAF, doublefree, format string, local privilege, file-associated DLL hijacking (excluding loading non-existent DLL files and loading normal D LL unchecked legitimacy), and others native code execution vulnerability caused by a logic issue.

5. Vulnerabilities to directly obtain client permissions. Includes, but is not limited to, remote arbitrary command execution, remote buffer overflows, available ActiveX stack overflows, browser use after free vulnerabilities, remote kernel code execution vulnerabilities, and other remote code execution vulnerabilities caused by logical problems.

6. XSS vulnerabilities for critical client products that receive sensitive information or perform sensitive operations.

[Medium]

Score range 3-5, security coin range 45~75 (exchange security coin coefficient: Web/server 15; PC c/mobile terminal 15)

This level includes:

1. A vulnerability that requires interaction to obtain user identity information. Including but not limited to reflective XSS (including reflective DOM-X SS), JSONHijacking, CSRF for important sensitive operations, storage XSS for general services

2. Remote application denial of service vulnerability, sensitive information disclosure, kernel denial of service vulnerability, XSS vulnerability for client products that can obtain sensitive information or perform sensitive operations

3. General information disclosure vulnerability. Includes, but is not limited to, client plaintext storage passwords, source code compression package leaks containing sensitive information

[Low]

Score range 1-2, security coin range 9~18 (exchange security coin coefficient: Web/server 9; PC c/mobile terminal 9)

This level includes:

1. Vulnerabilities in user identity information can only be obtained in certain non-popular browser environments (such as IE6). Includes, but is not limited to, reflective XSS (including reflective DOM-XSS), storage XSS for general services, and so on.

2. Minor information disclosure vulnerability. Includes, but is not limited to, path leaks, SVN file leaks, phpinfo, logcat sensitive information leaks.

3. PC client and mobile client local denial of service vulnerability. Includes, but is not limited to, local denial of service vulnerabilities caused by component permissions.

4. Unauthorized access. Includes, but is not limited to, bypassing client proactive defense, Bitget URL jump vulnerabilities, and third-party URL hops that bypass the Bitget malicious URL detection mechanism (Note: Jumping to a normal website is not a jump vulnerability).

5. Problems that are difficult to exploit but may present a potential safety hazard. Includes, but is not limited to, Self-XS S, which may cause propagation and exploitation, non-critical sensitive operations, CSRF, and remote code execution vulnerabilities that require man-in-the-middle attacks and provide effective P oC.

[No]

Score range 0 (exchange security coin coefficient: Web/server 0; PC c/mobile terminal 0)

This level includes:

1. Unrelated security bugs. Including but not limited to webpage garbled, webpages cannot be opened, and a feature cannot be used.

2. "Vulnerabilities" that cannot be exploited. This includes, but is not limited to, scanner vulnerability reports that are not meaningful (such as lower versions of WebServer), Self-XSS, JSON Hijacking without sensitive information, CSRF without sensitivity operations (such as favorites, adding shopping carts, subscriptions for non-critical services, non-critical business ordinary personal data modification, etc.), meaningless source code leakage, intranet IP address/domain name leakage, 401 basic authentication phishing, program path trust problem, logcat information leakage without sensitive information.

3. No guess of evidence.

4. Non-Bitget business vulnerabilities.

The rating criteria are as follows:

Security Intelligence Scoring Standard

Security intelligence refers to information related to Bitget's products and business vulnerabilities, including but not limited to vulnerability cues, attack cues, attack related information, attack methods, and attack technologies. According to the hazard and information provided, the detailed scoring standards are as follows:

General Principle of Scoring Standards

1. The scoring criteria are only for threat intelligence that affects Bitget products and services. The domain name includes but is not limited to *.bitget.com, the server includes the server operated by Bitget, and the product is the client product released by Bitget. Threat intelligence that has no impact on Bitget business security, does not count.

2. Important client products are Bitget client products.

3. For products and services that are not directly released by Bitget or third-party application threat intelligence of the Bitget open platform, they are not scored.

4. For the client vulnerabilities (including PCs and mobiles) caused by third-party libraries (such as libpng, zlib, libjpeg, etc.), and the vulnerabilities that can be fixed by upgrading or replacing third-party libraries, only the first vulnerability reporters are scored. At the same time, from the feedback time of the first vulnerability obtained by BGSRC to the date when the first fixed version of the third party was released, the same type of vulnerability is scored as one vulnerability; the hazard level is assessed by the most harmful vulnerability.

5. For general-purpose vulnerabilities caused by mobile terminal systems, such as webkit uxss, code execution, etc., only the first vulnerability reporter is scored, and the same vulnerability report for other products is no longer scored separately.

6. Because client vulnerability auditing is complex and involves other development departments, the audit time may be longer than the WEB vulnerability. Sometimes the details of the vulnerabilities provided by the reporter are not detailed enough, which may cause BGSRC to fail to give conclusions within the original time. Please understand this. Therefore, please provide a poc/exploit when the feedback vulnerability is provided, and provide a corresponding vulnerability analysis to speed up the administrator processing. Vulnerability submissions that are not provided or not analyzed in detail by poc or exploit may directly affect the rating.

7. If multiple vulnerabilities are submitted to the same client within the same time period, please clearly identify the key code that caused the vulnerability and trigger the vulnerability to quickly confirm whether they are the same vulnerability and speed up the vulnerability confirmation.

8. Security issues arising from third-party generic vulnerabilities are based on the general vulnerability award criteria.

9. When a threat intelligence reporter reviews a security issue, if it finds that the security issue persists or is not fixed, it will continue to score as a new threat intelligence.

10. The same threat information, the first reporter scores, the other reporters do not score; the submitted threat information is not scored.

11. Reject scanner results without proof of actual damage.

12. Using security testing as an excuse to use intelligence information to harm the interests of users, affect the normal operation of the business, expose the public before the repair, steal data from users, etc., will not be accounted for, and Bitget reserves the right to take further legal action.

Rewarding Principle

[Regular Rewards]

1. Prizes are exchanged using a security coin(a cryptocurrency of BGSRC). The number of security coins is multiplied by the score of the threat intelligence by the corresponding hazard level factor. The hazard rating factor is referred to the “Threat Intelligence Scoring Criteria” section. The coefficient will be adjusted according to the actual situation, and each adjustment will be announced. The security coins generated by multiple threat intelligences can be accumulated, unless otherwise stated, the unused security coins will not expire.

2. The right to interpret the Vulnerability Reward Processing Standard is owned by the Bitget Security Department.

Dispute Resolution

In the process of threat intelligence processing, if the reporter has objections to the processing flow, threat intelligence assessment, threat intelligence score, etc., please communicate in time through the current threat intelligence mailbox. The Bitget Security Emergency Response Center will handle the priority of the threat intelligence reporters and, if necessary, introduce external parties to jointly decide.

FAQ

Q: How much is the 1 security coin of BGSRC?

A: According to industry award criteria, the current BGSRC 1 security coin is equivalent to approximately RMB 5.

Q: Will the threat information after Bitget receive threat intelligence feedback be made public?

A: In order to protect the interests of users, threat information will not be disclosed until the security issue of threat intelligence feedback is fixed. After the security issue is fixed, the threat intelligence reporter can make it public. BGSRC recommends that threat intelligence reporters categorize and summarize threat intelligence-related technologies and make them public in the form of technical articles.

Q: What is the relationship between BGSRC and other security groups?

A: Bitget security is inseparable from the support and help of the industry. BGSRC is willing to cooperate with various security groups to promote the healthy development of the security industry. Currently BGSRC has cooperated with some security groups and will have more cooperation in the future.

Q: Will Bitget first "ignore" the vulnerability and then secretly fix it?

A: Absolutely not. Once the submitted "vulnerabilities" enter the "ignore" state, following up with colleagues will leave the reason. A common occurrence is that this "vulnerability" is not considered a vulnerability and is assessed as a bug. BGSRC only knows the relevant product colleagues, whether to change this "bug" is determined by the product colleagues. Another situation is the change in the business itself, causing the “vulnerabilities” to cease to exist. But no matter what, Bitget will not "sneak fixes".