Bit2Me bug bounty

At Bit2Me we love hacker culture. We feel very identified with this philosophy that is part of our company's DNA. So much so that some of us participate in hackathons and CTFs (Capture-The-Flag) events. At Bit2Me, we are always willing to collaborate and organize events aligned with this mindset.

With the goal of society moving towards a world where cryptocurrencies like Bitcoin have greater acceptance, we work to build the best platform in the world for cryptocurrencies.

This will help us build a much fairer and more democratic world, without the monopoly of money, as currently happens with central bank money, where a few enslave the rest of humanity due to the way it functions.

We are aware of the frantic pace that a startup like ours can have (updates, new products, ...). As human beings, we are also aware that we are not perfect and we can forget something.

Therefore, hacker community, this document is a call to you. We make the best bug bounty we could create available to you, considering the current size of our company. As we grow, we will update it.

What do you need to know?

• Program rules
• Vulnerabilities already reported
• How will we do it? Cryptography to the power!
• What does this mean?
• Scope of action (scope)
• Vulnerabilities that will NOT be accepted
• How to report a bug?
• Response policy
• Rewards
• Examples of vulnerabilities we are looking for:
• Hall of Fame

Program rules

• You must add the header "X-BUGBOUNTY-HACKER: <your_hacker_name>" when performing tests so that we can identify your requests.
• Only reports of previously unreported vulnerabilities will be accepted. In case of duplicates, the first reporter will always be rewarded (provided they have complied with the rules set out here, otherwise, it will proceed in order of report from oldest to most recent).
• Provide sufficient evidence and information for our team of engineers to reproduce and fix the vulnerability.
• Do not display any type of illegal conduct when disclosing the vulnerability to Bit2Me, such as threats, lawsuits, or other types of coercive tactics.
• Do not exploit the vulnerability in such a way that it could publicly exfiltrate sensitive information, nor obtain benefit from the exploitation of the vulnerability prior to obtaining the reward from Bit2Me.
• Do not perpetrate the destruction of data or interruption of any Bit2Me service in the process.
• Report only one vulnerability per request, unless it is necessary to chain vulnerabilities to maximize the impact on a type of vulnerability.
• Do not report a vulnerability caused by an underlying problem that is the same as a problem for which a reward has been paid under this Program.
• Several vulnerabilities caused by one underlying problem will receive a single reward.
• A single vulnerability reproducible in more than 1 service or subdomain will be treated as a single vulnerability.
• Publication on any Internet medium of any successfully carried out exploitation during participation in the Bug Bounty program is not allowed. In case of violation of this rule, future requests to that member will be denied, and their pending reward payments will be suspended.

Vulnerabilities already reported

A normal question you might ask yourself, and rightly so, is: How can I be sure that Bit2Me will be honest in rejecting the vulnerability by justifying that the vulnerability was already reported?

As one of the famous slogans of the cryptocurrency world says: “Don’t trust, Verify!"

As you know, we love to innovate, and we love blockchain technology. With this in mind, and to set an example with the values and advantages that Blockchain technology brings, every reported and accepted vulnerability will be published on the Blockchain.

How will we do it? Cryptography to the power!

Once a vulnerability is reported and accepted, even before it is resolved by our team, we will do the following: 

1. We will take all the vulnerability information and create a report in PDF format.

2. From the newly created PDF report, we will generate a digital fingerprint (hash checksum).

3. We will issue a transaction to the Ethereum blockchain, including the generated hash of the document in it.

This transaction will remain transparent and immutable on the network forever, being totally impossible to alter, and reflecting the exact moment it was created.

What does this mean?

If that hash existed at that time, it means that the document, and with it the information it contains, also existed.

If, subsequently, someone reports a similar vulnerability to us, we will provide them with the PDF report and the transaction. 

With the report, they will be able to generate the digital fingerprint themselves and verify that the hash was already registered in the past, thanks to the provided Ethereum transaction, where they can see the exact date of it.

For the hash / checksum of the report, we will use the SHA-512 algorithm.

Scope of action (scope)

We have limited the area of action for finding vulnerabilities to the following domains / subdomains:

• bit2me.com

• account.bit2me.com

• wallet.bit2me.com

• converter.bit2me.com 

• explorer.bit2me.com

• gateway.bit2me.com

• Bit2Me Android and iOS Applications
  
  

Vulnerabilities that will NOT be accepted

• Any asset outside the indicated scope.
• Although denial of service (DoS) vulnerabilities are allowed, either due to code inconsistencies, outdated services on the platform, or libraries that generate excessive cyclomatic loops, distributed denial of service (DDoS) attacks are outside the scope, such as attacks through botnets or with flooding tools.
• Account/email enumeration.
• Brute-force attacks.
• Content spoofing and text injection without the ability to modify HTML/CSS.
• Self-exploitation (such as successful XSS only executed locally, console scripting, token reuse, etc.).
• Permissive CORS headers.
• Clickjacking with minimal impact actions.
• Tab-nabbing.
• Vulnerabilities related to form auto-completion.
• Lack of headers or flags (CSP, X-Frame-Options, Strict-Transport-Security, Content-sniffing, HTTPOnly flag, link attributes "noopener noreferrer", etc.) that cannot lead to direct exploitation.
• Lack of good practices in SSL/TLS configuration.
• Support for HTTP methods like OPTIONS.
• CSRF attacks without compromising authentication or critical operations (adding to favorites, logout, etc.).
• Exposure of outdated software or service versions.
• Exposure of public directories or files (such as robots.txt) with minimal impact.
• Bugs in non-common browsers or in browsers not supported by Bit2Me.
• MITM attacks that require physical access to a user's device.
• Any physical attack against Bit2Me's properties or its data centers.
• Publicly accessible login panels.
• UX or usability issues that do not imply security flaws.
• Issues that have no security impact (e.g., page loading failure).
• Social engineering, phishing, vishing, smishing against employees, suppliers, customers, or users of Bit2Me.
• Vulnerabilities already known by us or already reported by someone (the reward will go to the first reporter).
• Others…

How to report a bug?

Send your report to the email address: security@bit2me.com.

Include the greatest number of possible pieces of evidence: title of the exploited vulnerability, description of each step in the exploitation, tools used in the exploitation, browser version, attach screenshots (or even video), etc.

Include the PoC (Proof of Concept), if you carried it out. It will be mandatory to include an explanation of how to correct the reported vulnerability.

Wait up to 10 business days for our team to study your request and receive a response about whether we have accepted your request. If accepted, the reward will be paid within the period stipulated in the Response Policy (*see response policy).

Response policy

Bit2Me will always do its best to follow the following response policy for requests sent by hackers participating in our program:

Our maximum time for responses regarding the acceptance of the vulnerability (from receipt of the report) is: 10 business days.

Payment of the reward will be made when the vulnerability is resolved. This period may be delayed days, or even weeks.

Payments can be made in the following way:

• Cryptocurrencies: We love cryptocurrencies, and if you do too, it will be a pleasure to pay your reward in cryptocurrencies such as Bitcoin, Ethereum, Monero, or others.

Rewards

The rewards granted by Bit2Me range from €50 for low vulnerabilities up to €5,000 for highly critical ones.

Normal rewards will be administered based on our criteria for the criticality of the vulnerability:

For vulnerabilities that the company's internal cybersecurity team considers VERY critical, Bit2Me has a special reward of €5,000.

Examples of vulnerabilities we are looking for:

• XSS (excluding self-XSS).
• CSRF (excluding CSRF involving actions with no impact).
• Remote Code Execution.
• Authentication Bypass.
• SQL Injection.
• Sensitive information leakage.
• LFI/RFI.
• Privilege Escalation.
• Vulnerabilities that can cause loss of user funds or assets.
• Vulnerabilities that can cause remote leakage of confidential company data.

Hall of Fame

All persons, or entities, who report rewarded vulnerabilities will be published, if they wish.

These are the members who, as of today, have reported an accepted vulnerability:

• Ch Chakradhar
• White Coast Security Private Limited
• Abhishek Pal
• Javier Andreu
• Pratik Yadav
• Sachin Pandey
• Shashank Jyoti
• Moein Abas
• Yash Ahmed Quashim
• Volodymyr "Bob" Diachenko
• Fahim Ali
• Felipe Martinez
• Taniya & Rohan
• Shubham Kushwaha
• Pawan Rawat
• Akash Hamal
• Mehedi Hasan
• Anchal Vij
• Soumen Jana
• Rohan
• Mayank Sahu
• Kartik Singh
• Niket Popat