Onderwerpen
    Bybit Bug Bounty Program
    bybit2024-10-17 16:11:25

    Does Bybit have a bug bounty program? 

    Yes, Bybit has a bug bounty program. If you notice a vulnerability on Bybit and would like to obtain a bug bounty, please refer to the steps below:  

    Step 1: Consolidate all your findings in a neat and organized format. Providing GIFs or video recordings of the bug will be most appreciated. 

    Step 2: Submit your security report and findings via this form and select the option API Trading / Report a Security Vulnerability.

    For video recordings, please upload it to Google Drive and send us the shareable link. For more information on how to do so, please visit here.


     

    What is the bug bounty given out when a vulnerability is approved?

    Please refer to the table below for the bug bounty available based on the level of the vulnerability detected. 
     

    Level

    Bounty

    Low

    50 to 200 USDT

    Medium

    500 to 1000 USDT

    High

    1000 to 2000 USDT

    Critical

    2500 to 4000 USDT




     

    How are the various levels of bugs/vulnerabilities defined? 

    Please refer to the list below for more information:
     

    Critical Vulnerabilities

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

     

    A critical vulnerability includes, but is not limited to:

    • Multiple devices access the internal network
    • Gaining core back-end super administrator access, leaking enterprise core data and causing severe impact
    • Smart contract overflow and conditional competition vulnerability

     

    High-Risk Vulnerabilities

    • Gain system access (getshell, command execution, etc.)
    • System SQL injection (back-end vulnerability degradation, prioritization of package submission as appropriate)
    • Gaining unauthorized access to sensitive information, including but not limited to direct access to the management background by bypassing authentication, brute force attackable back-end passwords, or to obtain SSRF of sensitive information in the internal network, etc.
    • Arbitrary document reading
    • XXE vulnerability that can access any information
    • Unauthorized operation that involves money or payment logic bypassing (needs to be successfully utilized)
    • Serious logical design defects and process defects. This includes, but is not limited to, any user login vulnerability, 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. These include but are 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 be successfully utilized
    • Leakage of source code
    • Permission control defects in the smart contract

     

    Medium-Risk Vulnerabilities

    • A vulnerability that can affect users by interaction, including but not limited to storage XSS on general pages, CSRF involving core business, etc.
    • General unauthorized operation, not limited to modifying user data and performing user operation by bypassing restrictions
    • Denial-of-service vulnerabilities, including but not limited to remote denial-of-service vulnerabilities caused by denial-of-service of web applications
    • 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
    • Leakage of locally-stored, sensitive authentication key information, which needs to be available for effective use

     

    Low-Risk Vulnerabilities

    • Local denial-of-service vulnerabilities include, but are not limited to, client local denial-of-service (parsing file formats, crashes generated by network protocols), problems caused by Android component permission exposure, general application access, etc.
    • General information leakage, not limited to Web path traversal, system path traversal, directory browsing, etc.
    • XSS (including DOM XSS/Reflected XSS)
    • General CSRF
    • 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, such as CORS vulnerability that cannot access sensitive information) 
    • No return value and no in-depth utilization of successful SSRF

     

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

    • Email spoofing
    • User enumeration vulnerability
    • Self-XSS & HTML injection
    • Web pages lacking CSP and SRI security policies
    • CSRF issues for non-sensitive operations
    • A separate issue concerning the Android app android:allowBackup=”true”, in which service is denied locally, etc. (except for in-depth use)
    • Problems such as changing the size of the image, causing slow requests, etc.
    • Version leak issues, such as NGINX, etc.
    • Some functional bugs that don’t pose a security risk issue
    • Physical attack on Bybit /social engineering attack on Bybit employees

     

    Prohibited Behaviors

    • Conducting social engineering and/or engaging in phishing
    • Leaking details of a vulnerability
    • Vulnerability testing is limited to PoC (proof of concept), and destructive testing is strictly prohibited. If harm is caused inadvertently during the testing, it should be reported in time. Meanwhile, sensitive operations performed during the test, such as deletion, modification and other operations, must be explained in the report
    • Using 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/or obtaining an aggressive payload such as user information (for blind xss testing, please use dnslog). If you accidentally use a more aggressive payload, please delete it immediately. Otherwise, we have the right to pursue related legal liabilities.
    Was it helpful?
    yesYesyesNo