Bug Bounty | 3Commas
This Bug Bounty is effective of April 12, 2024.
Firstly, thank you for your interest in our Bug Bounty program and helping us to make our platform stronger and safer. Even with the best efforts of our expert team and making every effort to squash bugs in our systems, there's always the chance that we might have missed one that poses a significant threat.
If you discover a bug, we welcome your cooperation in responsibly investigating and reporting it to us so that we can address it as soon as possible.
1. Introduction
1.1 Purpose of the Bug Bounty Policy
The purpose of this Bug Bounty Policy is to establish guidelines and procedures for conducting a bug bounty program. The program aims to leverage the collective expertise of security researchers and ethical hackers to identify and report vulnerabilities in our systems, applications, and network infrastructure. By engaging the security community, we strive to improve the overall security posture of our organization and protect our assets from potential threats.
1.2 Scope and Application
This Bug Bounty Policy applies to systems, applications, and infrastructure owned or operated by our organization that are expressly included in the currently defined scope below. It encompasses both web-based and mobile applications, APIs, and any other technology assets that fall within the defined scope of the bug bounty program.
Currently defined scope:
- Customer Cabinet Domain:
Domain: https://app.3commas.io/
Description: This domain refers to the main customer cabinet of the organisation, where users can access and manage their accounts and investments. - API Interactions Domain:
Domain: https://api.3commas.io/
Description: This domain represents the API interactions used by the organization's systems and applications, which are also within the scope of the bug bounty program. - iOS Application:
Application: https://apps.apple.com/app/id6446649413
Description: The organization has an iOS application available for users to download and use on their iOS devices. Security researchers can assess the application for vulnerabilities as part of the bug bounty program. - Android Application:
Application: https://play.google.com/store/apps/details?id=io.threecommas.wallet
Description: The organisation has an Android application for users to download and use on their Android devices. Security researchers can assess the application for vulnerabilities as part of the bug bounty program.
The Bug Bounty Policy covers all of these domains and applications to ensure comprehensive security testing of the organisation's systems, applications, and infrastructure by external security researchers.
Explicitly excluded scope:
- Feedback portal:
Domain: https://feedback.3commas.io/
Description: This domain is a 3rd party portal for feedback collection. - Careers portal:
Domain: https://careers.3commas.io/
Description: This domain is a 3rd party portal that manages career opportunities. - Careers portal:
Domain: https://3commas.tech/
Description: This is our experimental project outside of the Bug bounty program.
1.3 Definition of Terms
To ensure clarity and a common understanding of key concepts related to the Bug Bounty Program, the following terms and definitions apply:
Bug Bounty Program | A coordinated effort that rewards individuals for responsibly disclosing security vulnerabilities in systems or applications. |
Security Researcher | An individual who actively searches for security vulnerabilities to identify and report them to the program organizers. |
Confidentiality | The requirement to keep vulnerability information private and not disclose it to unauthorized individuals or publicly before authorized disclosure. |
Non-Disclosure Agreement (NDA) | A legal agreement between the participant and the program administrators that outlines the confidentiality obligations and restrictions regarding vulnerability information. |
Duplicate Report | A vulnerability report that shares the same characteristics, impact, and details as a previously reported vulnerability. |
Weakness / Flaw | An implementation imperfection, defect or characteristic that may lead to undesirable behavior. |
Vulnerability | Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. |
Common Vulnerability Scoring System (CVSS) | A framework for assessing and scoring the severity of vulnerabilities based on their characteristics and potential impact. |
Proof of Concept (PoC) | Evidence of the feasibility of a particular method. In the context of this policy — a non-harmful demonstration provided by a participant to illustrate the existence or exploitability (potential to compromise confidentiality, integrity, or availability) of a reported vulnerability. |
Impact | The magnitude of harm that can be expected to result from the consequences of unauthorised disclosure of information, unauthorised modification of information, unauthorised destruction of information, or loss of information or information system availability. |
Threat | Any circumstance or event with the potential to adversely impact organisational operations (including mission, functions, image, or reputation), organisational assets, or individuals through an information system via unauthorised access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a vulnerability. |
Risk | A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and the likelihood of occurrence. |
Note
Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organisational operations (including mission, functions, image, or reputation), organisational assets, individuals, and other organisations.
Responsible Disclosure / Coordinated Vulnerability Disclosure (CVD) | The act of reporting security vulnerabilities to the program organisers in a responsible manner allows them to remediate the issues before disclosing them publicly. |
2. Bug Bounty Program Overview
2.1 Objectives of the Bug Bounty Program
The Bug Bounty Program aims to achieve the following objectives:
- Identify and mitigate security vulnerabilities before malicious actors can exploit them.
- Encourage responsible disclosure by recognising and rewarding security researchers who report valid vulnerabilities.
- Enhance the overall security posture of our organisation's systems and applications.
- Foster collaboration with the security community and build positive relationships with ethical hackers.
2.2 Program Participants
The Bug Bounty Program is open to all security researchers who meet the eligibility requirements outlined in Section 3.1. Participants must adhere to the program guidelines and rules, maintain confidentiality, and act ethically throughout the testing process.
2.3 Program Guidelines and Rules
To ensure the success and fairness of the Bug Bounty Program, participants must comply with the following guidelines and rules:
- Obtain explicit authorisation before conducting any testing.
- Respect the defined scope and limitations of the program.
- Report vulnerabilities promptly and responsibly.
- Refrain from performing actions that could cause harm or disrupt services.
- Adhere to the responsible disclosure principles outlined in Section 7.2.
2.4 Program Duration and Termination
The Bug Bounty Program will have a defined duration, starting from the program launch date specified by our organisation. The program may be terminated or suspended at any time at the organisation's discretion.
3. Eligibility and Participation
3.1 Eligibility Requirements
To participate in the Bug Bounty Program, security researchers must meet the following eligibility requirements:
- Must be at least 18 years old or of legal age in their respective jurisdiction.
- Must not be an employee, contractor, or affiliate of our Company.
- Must not be prohibited by law or regulations from participating in such programs (must not be subject to sanctions, etc.).
- Must comply with all applicable laws and regulations.
3.2 Participant Responsibilities
Participants in the Bug Bounty Program have the following responsibilities:
- Adhere to the program guidelines and rules outlined in Section 2.3.
- Respect the defined scope and limitations of the program.
- Conduct testing activities in a lawful and ethical manner.
- Provide accurate and detailed reports of identified vulnerabilities.
- Cooperate with the program administrators during the vulnerability assessment and remediation process.
- Maintain professional and respectful communication throughout their engagement; any use of offensive language or inappropriate behaviour may result in disqualification of the report.
3.3 Exclusions and Limitations
The Bug Bounty Program has certain exclusions and limitations that participants should be aware of:
- Section 8.2 lists the types of issues the reports of which will not be rewarded and shall not be reported under this Program.
- Social engineering attacks, physical attacks, and denial-of-service (DoS) attacks are strictly prohibited.
- Any attempts to access, modify, or destroy data belonging to other users or third parties are prohibited.
- Vulnerabilities in third-party applications or systems not owned or operated by our organisation are excluded from the scope.
- Participants are not authorised to publicly disclose vulnerabilities before receiving approval from the program administrators.
It is essential for participants to thoroughly review and understand the eligibility requirements, responsibilities, and exclusions to ensure compliance with the Bug Bounty Program.
4. Vulnerability Submission Process
4.1 Reporting Vulnerabilities
To report a vulnerability discovered during the Bug Bounty Program, participants should follow the established submission process. This typically involves the following steps:
- Create a detailed report outlining the vulnerability, including steps to reproduce and any supporting evidence or proof-of-concept (PoC) code.
- Submit the vulnerability report through the designated reporting channel specified by the program administrators. This can be an online portal, email address, or bug bounty platform.
- Include relevant information such as the affected system or application, version numbers, and any other pertinent details requested by the program administrators.
A proof-of-concept is required to review reports of medium and higher severity.
4.2 Vulnerability Assessment and Validation
Upon receiving a vulnerability report, the program administrators will review and assess its validity and impact. This process may involve:
- Replicating the reported vulnerability to verify its existence and impact.
- Assessing the severity and potential risk associated with the vulnerability using the Common Vulnerability Scoring System (CVSS) version 3.1.
- Determining if the vulnerability falls within the defined scope of the Bug Bounty Program.
- Communicating with the reporting participant for further clarification or additional information, if needed.
4.3 Response Timeframes
The Bug Bounty Program aims to provide timely responses to participants. The program administrators will acknowledge the receipt of the vulnerability report within two business days. For the initial assessment and response, a maximum of 10 business days (after acknowledgement) will be allowed. Depending on the complexity and severity of the reported vulnerability, additional time may be needed for a thorough evaluation and remediation planning.
4.4 Confidentiality and Non-Disclosure
The Bug Bounty Program places great importance on maintaining the confidentiality of reported vulnerabilities. Participants are required to adhere to the following principles:
- Keep all information related to identified vulnerabilities confidential until authorised for public disclosure by the program administrators.
- Avoid sharing vulnerability details with unauthorised individuals or disclosing them publicly on forums, social media, or other platforms.
- If necessary, participants can share vulnerability details with the program administrators in a secure and confidential manner.
It is crucial for participants to follow the vulnerability submission process and respect the principles of confidentiality to ensure a smooth and secure Bug Bounty Program.
5. Vulnerability Classification and Rewards
5.1 Scoring methodology
This information in your bug report effectively communicates that the CVSS v3.1 framework was used to assess the vulnerability's severity, making it easier for bug bounty program administrators to evaluate and respond to your report accurately.
Reference to CVSS v3.1 documentation is located at https://www.first.org/cvss/v3.1
5.2 Vulnerability Severity Levels
Vulnerabilities discovered during the Bug Bounty Program will be classified into the following severity levels based on their CVSS (Common Vulnerability Scoring System) score:
Low | 0.1 – 3.9 |
Medium | 4.0 – 6.9 |
High | 7.0 – 8.9 |
Critical | 9.0 – 10.0 |
5.3 Reward Structure
Rewards for valid vulnerabilities will be calculated based on the following table:
CVSS Severity Rating | Minimum amount | Maximum amount |
|---|---|---|
Low | 50 USDT | 200 USDT |
Medium | 200 USDT | 1000 USDT |
High | 1000 USDT | 2500 USDT |
Critical | 2500 USDT | 5000 USDT |
The actual payout amount within the given range will be determined based on the severity assessment of the vulnerability. All calculations and rewards are solely at the discretion of the Program Administration, and all determinations by the Program Administration regarding a reward are final and binding (outlined in Sections 6.1 and 6.2).
5.4 Issues excluded from the scope
See Section 8.2 for a listing of issues, the reports of which will not be rewarded and shall not be reported under this Program.
6. Program Governance and Legal Considerations
6.1 Program Administration
The Bug Bounty Program will be administered by a designated team responsible for overseeing the program's operations. The program administrators will have the following responsibilities:
- Receiving and triaging vulnerability reports submitted by participants.
- Conducting initial assessments and validations of reported vulnerabilities.
- Communicating with participants regarding the status and progress of their reports.
- Coordinating with relevant stakeholders for vulnerability remediation and verification.
- Ensuring compliance with the Bug Bounty Policy and program guidelines.
6.2 Disqualification and Disputes
The program administrators reserve the right to disqualify participants from the Bug Bounty Program in cases where:
- Participants violate the Bug Bounty Policy or program guidelines.
- Participants engage in any malicious activities or unauthorised actions.
- Participants fail to adhere to responsible disclosure principles.
- Participants intentionally cause damage or disrupt services.
In the event of disputes or disagreements regarding vulnerability severity, reward amounts, or eligibility, participants can reach out to the program administrators for resolution. The program administrators' decisions will be final and binding.
6.3 Legal Compliance
Participants in the Bug Bounty Program must comply with all applicable laws and regulations during their engagement. This includes, but is not limited to:
- Conducting vulnerability testing and reporting activities within legal boundaries.
- Respecting intellectual property rights and not infringing upon any copyrights, trademarks, or patents.
- Protecting the privacy and confidentiality of individuals and their personal information.
Our organisation will also ensure compliance with legal obligations, including data protection and privacy regulations, throughout the Bug Bounty Program.
6.4 Sanctions Compliance
6.4.1. By participating in the 3Commas’ Bug Bounty Program, you represent and warrant that you:
6.4.1.1 have not been included in any trade embargos or economic sanctions lists, including but not limited to:
- Restrictive measures of the European Union;
- Sanctions of the United Nations;
- Sanctions of the Government of Estonia;
- the list of specially designated nationals maintained by Office of Foreign Assets Control (OFAC) of the U.S. Department of the Treasury;
- the denied persons or entity list of the U.S. Department of Commerce;
- Lists of subjects to Financial Sanctions maintained by the UK Office of Financial Sanctions Implementation (OFSI),
6.4.1.2 your participation, use and access of 3Commas services does not violate or circumvent international sanctions and restrictive measures established by the European Union, United Nations, United States of America, United Kingdom or other international sanctions applicable in the Republic of Estonia, and
6.4.1.3 are not from any countries or geographical regions currently under sanctions imposed by the European Union, United Nations, United States of America, United Kingdom, and/or any other international sanctions applicable in the Republic of Estonia.
6.4.2. We reserve the right to choose markets and jurisdictions to conduct business, and may restrict or refuse, in our sole discretion, the provision of 3Commas services in certain countries or regions, including those not mentioned herein.
6.4.3. If you become subject to international sanctions, you are obliged to immediately stop using our services and notify us.
6.4.4. Without prejudice to other grounds for such actions available to us, we have the right to terminate, suspend or restrict the provision of 3Commas’ services to you as well as to terminate these Terms of Use in case:
6.4.4.1. you become a subject of international sanctions,
6.4.4.2. providing services to you is considered a violation or circumvention of international sanctions,
6.4.4.3. you are according to our assessment related to a territory, area of activity, transaction or person subject to international sanctions, or
6.4.4.4. we apply our right referred to in Section 6.4.2
6.5 Tax Compliance
In accordance with our Bug Bounty Program policy, all participants are responsible for any applicable taxes on the reward payments they receive. It is essential to understand that bug bounty rewards may be considered taxable income in various jurisdictions.
6.6 Privacy and Data Protection
The Bug Bounty Program will handle participants' personal information and vulnerability data in accordance with applicable privacy and data protection laws. Personal information collected during the program will be used solely for the purpose of administering the Bug Bounty Program and rewarding participants. Our organisation will take appropriate measures to protect the confidentiality and integrity of participants' information.
Participants should refrain from accessing, exfiltrating, or tampering with personal data belonging to others and promptly report any accidental access or exposure of personal information discovered during testing.
It is essential for participants to comply with legal requirements and maintain the privacy and confidentiality of both our organisation's and individuals' data throughout the Bug Bounty Program.
Our organisation adheres to stringent measures designed to protect the confidentiality and integrity of participants' information. In addition to this commitment, all data processed during the Bug Bounty Program will also adhere to the guidelines and principles outlined in our Privacy Notice, which can be found at https://3commas.io/privacy-notice. This Privacy Notice provides detailed information about how we collect, use, and protect your personal data.
7. Public Disclosure and Acknowledgments
7.1 Public Disclosure Policy
Public disclosure of vulnerabilities discovered during the Bug Bounty Program must follow the responsible disclosure principle. Participants are prohibited from publicly disclosing any vulnerability or related details without obtaining prior approval from the program administrators. Public disclosure includes sharing information on public forums, social media, blogs, or any other publicly accessible platform.
Once a vulnerability has been validated, participants should allow the program administrators a reasonable amount of time to address and remediate the issue before any public disclosure occurs. This allows our organisation to protect its systems and users effectively.
7.2 Responsible Disclosure Principles
Participants are expected to follow responsible disclosure principles when reporting vulnerabilities. This includes:
- Providing sufficient time for our organisation to assess, validate, and remediate the reported vulnerability before public disclosure.
- Cooperating with our organisation during the vulnerability remediation process and adhering to any specific guidelines or requirements.
- Avoiding any malicious or harmful activities that could compromise the security or integrity of our systems or data.
- Respecting any non-disclosure agreements or confidentiality obligations agreed upon with our organisation.
Our organisation acknowledges the effort and contribution of participants in identifying vulnerabilities and reserves the right to publicly acknowledge and recognise their contributions, subject to the participant's consent.
7.3 Acknowledgements and Recognition
Our organisation values the contributions and efforts of participants in the Bug Bounty Program. As a token of appreciation, we offer the following acknowledgements and recognition:
- Acknowledgement: Participants who report valid vulnerabilities will receive an acknowledgement from our organisation. This acknowledgement may come in the form of a personalised thank-you message, a certificate, or a written acknowledgement of their contribution.
- Swag and Rewards: In addition to financial rewards for valid vulnerabilities, participants may also receive exclusive program-branded merchandise or other promotional items as a gesture of appreciation.
- Public Recognition: With the participant's consent, our organisation may publicly recognise their contributions through blog posts, social media mentions, or case studies. This recognition highlights their efforts and helps establish their reputation within the security community.
The specific acknowledgements and recognition provided will be determined by our organisation based on the significance and impact of the reported vulnerabilities.
8. Appendices
8.1 Vulnerability Reporting Template
Participants can use the following template when submitting a vulnerability report:
Title | Brief and descriptive title of the vulnerability |
Description | Provide a detailed description of the vulnerability, including the affected system or application and how it can be exploited. |
Steps to Reproduce | Outline the specific steps taken to reproduce the vulnerability. Include any input data, URLs, or conditions necessary for exploitation. |
Impact Assessment | Assess the potential impact of the vulnerability on the confidentiality, integrity, and availability of the system or data. |
Proof of Concept (PoC) | Include any supporting evidence, such as code snippets or screenshots, demonstrating the existence or exploitability of the vulnerability. |
Additional Information | Provide any other relevant information, such as the version numbers of the affected software or system configurations. |
Contact Information | Include your contact details, such as email address or preferred method of communication. |
Reward wallet | Provide the wallet address for your TRC20 tokens where you would like to receive the reward. |
8.2 Issues excluded from scope
At present, the issue categories and specific circumstances listed below are put out of the scope of this program. Reports of them will not be accepted by the Program Administration.
- Clickjacking on pages with no sensitive actions
- Clickjacking/UI redressing with minimal security impact
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Issues resulting in an application-level crash, or simply mentioning the possibility of MITM, SQL, or another type of injection without an exploit.
- Known vulnerable libraries without a working Proof of Concept.
- Comma Separated Values (CSV) injection without demonstrating a vulnerability.
- Missing best practices in SSL/TLS configuration.
- Issues related to unsafe SSL/TLS cipher suites or protocol versions
- Any activity that could lead to the disruption of our service (DoS).
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Rate limiting or bruteforce issues on non-authentication endpoints
- Missing best practices in Content Security Policy.
- Cookies without HttpOnly/Secure/SameSite attributes
- Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
- Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
- Software version disclosure / Banner identification issues / Descriptive error messages or headers and other benign information disclosures (e.g. stack traces, application or server errors, etc.).
- Public Zero-day vulnerabilities that have had an official patch for less than one month will be awarded on a case by case basis.
- Tabnabbing
- Issues that require unlikely user interaction
- Attacks that the reporter has already exploited themselves, leading to damage
- Attacks requiring access to leaked keys/credentials
- Broken link hijacking is out of scope, unless the resources hosted there are directly embedded into the application's frontend code and can influence its execution (external JavaScript, HTML, etc.)
- Attacks requiring MITM or physical access to a user's device.
- Non-technical attacks, such as a physical attack, social engineering, phishing, etc. (E.g. HTTP Basic Authentication Phishing)
- Attacks which require the user to add a network with a malicious RPC server
- Non-security-impacting UX issues
- Vulnerabilities or weaknesses in third-party applications that integrate with applications in scope
- Enablement of 2FA without email confirmation
- Existing authentication sessions are not expiring after 2FA enablement.
- Session invalidation issues (logout not expiring sessions)
- Password, email, and account policies, such as email address verification, password complexity.
- Password reset token leaks without demonstrating a vulnerability.
- Reporting a leaked token without first confirming it is valid and has access to sensitive operations
- Presence of autocomplete attribute on web forms
- Blind SSRF without proven business impact (DNS pingback only is not sufficient)
- "Mobile browser issues that do not have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:
undefinedundefinedundefined - OS-related vulnerabilities
- Wordpress -- CORS policy, xmlrpc, user enumeration, and other inconsequential WP-specific findings
- Site or domain configuration
- DNSSEC Misconfiguration
- Insecure configurations without a working PoC that demonstrates practical impact.
- Reports from automated tools or scans without working PoCs.
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github, will be considered out of scope without proof that they are in-use in production
- Self XSS
- Upload of malicious files via s3 pre-signed URLs where impact cannot be demonstrated.
- Arbitrary file upload
- Exposure of internal IP address or domains
- Any URIs leaked because a malicious app has permission to view URIs opened
- Shared links leaked through the system clipboard.
- Invalid or stale employee credential dumps - we already monitor haveibeenpwned.com and other sources for dumps of this nature.
- Documentation errors. We strive to keep the documentation up to date, but sometimes it becomes stale.
- Auth "app secret" hard-coded/recoverable in APK.
- Deficiencies in binary reverse engineering and run-time protections (anti-debugging, anti-decompiling, etc.)
- Path disclosure in the binary
- Snapshot/Pasteboard leakage
- Runtime hacking exploits only possible in a jailbroken/rooted environment
8.3 Contact Information
For vulnerability reports and program inquiries, please fill out this form: https://3commas.zapier.app. Encrypted communication might be requested on demand.
