Bit2Me bug bounty
Wed, 3 Jan, 2024 at 11:34 AM
At Bit2Me we love hacker culture. We ourselves have that mentality and we feel very identified with this way of thinking. Proof thereof is the fact that some of us participate in hackathons and CTFs (Capture-The-Flag) sessions, and we are always open to collaborate in the organization of events aligned with that thought.
We want to make the best platform in the world for cryptocurrencies, so that with it we can take steps as a society towards a world where cryptocurrencies like Bitcoin have a great acceptance, making a world much more fair and democratic, without a monopoly of money, as currently it happens with the money of the central banks where just a few enslave the rest of humanity because of the way money works.
But we are aware of the frenetic pace that a startup like ours could have (updates, new products, ...) and as human beings, we are also aware that we are not perfect and we could forget something.
That’s why, hacker community, this document is an appeal to you. We put at your disposal the best bug bounty that we have been able to create, taking into account our current company size, which we will keep on updating as we grow.
- You must set the header "X-BUGBOUNTY-HACKER: <your_hacker_name>" when you test so we can identify your requests
- Only reports of vulnerabilities not previously reported will be accepted. In the case of duplicates, only the first informant will be rewarded (as long as he has complied with the rules explianed here, by default, it will be followed by order of reporting from oldest to most recent).Provide enough evidence and information so that our engineering team can reproduce and solve the vulnerability.
- Do not show any type of illegal behavior when disclosing the vulnerability of Bit2me, such as threats, lawsuits or other type of coercive tactic.
- Do not exploit the vulnerability in such way that it could exfiltrate sensitive information in public, as well as not obtain benefit from the exploitation of the vulnerability prior to obtain the Bit2me reward.
- Do not perpetrate data destruction or interruption of Bit2me service during the process.
- Report only one vulnerability per request, unless you need to chain vulnerabilities to maximize the impact on a vulnerability type.
- Do not report a vulnerability caused by an underlying issue that is the same issue for which a reward has been paid under this Program.
- Multiple vulnerabilities caused by an underlying issue will receive a single reward.
- The same reproducible vulnerability in more than 1 service or subdomain will be treated as a single vulnerability.
- It is not allowed to publish in any Internet media any operation realized successfully during participation in the Bug Bounty program. In case of violation of this rule, future applications to this member will be denied and his/her pending reward payments will be suspended.
Vulnerabilities already reported
A normal question that you can ask yourself, and with good reason, is: How can I be sure that Bit2Me will be sincere in rejecting the vulnerability justifying that the vulnerability has already been reported?
As one of the famous lemmas in the cryptocurrency world says: "Don’t trust, Verify!"
As you know we love to innovate, and we love cryptocurrency technology. With this in mind, and to set an example with the values and advantages that Blockchain technology brings, all reported and accepted vulnerabilities will be published on the Blockchain.
How will we do it? Cryptography to power!
Once a vulnerability has been reported and accepted, before even being solved by our team, we will do the following:
- We will take all the information about the vulnerability and create a report in PDF format.
- From recently created PDF report we will generate a fingerprint (hash checksum).
- We will submit a transaction to the Ethereum blockchain including in it the generated hash of the document.
This transaction will remain transparent and immutable on the network forever, totally impossible to alter and reflected at the exact moment it was created.
What does this mean?
If that hash existed at that moment, it means that the document and all information in it, would also exist.
If someone later reports a similar vulnerability to us, we will provide you with the PDF report, and the transaction.
With the report you will be able to generate the fingerprint yourself and verify that this hash has already been registered in the past, thanks to the Ethereum transaction provided, where you can see the exact date of it.
For the hash / checksum of the report we will use the SHA-512 algorithm.
Scope of action
We have limited the area of action to search for vulnerabilities to the following domains / subdomains:
- Bit2me de Android e iOS Application
Vulnerabilities that will NOT be accepted
- All assets outside the specified scope.
- Even if vulnerabilities are allowed when produce a denial of service (DoS) whether due to code inconsistencies, outdated services on the platform or bookstores that generate excessive cyclomatic loops, denials of service in a distributed way fall outside the scope (DdoS), such as attacks through botnets or flooding tools.
- Enumeration of accounts / emails.
- Brute force attacks.
- Content spoofing and text injection without the ability to modify HTML / CSS.
- Auto exploitation (such as successfully XSS only executed locally, console scripting, token reuse ...).
- Permissive CORS headers.
- Clickjacking with minimal impact actions.
- Vulnerabilities related to autocomplete forms.
- 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 as OPTIONS.
- CSRF attacks without compromising authentication or critical operations (add to favorites, logout, etc.).
- Exposure of out-of-date software or service versions.
- Exposure of public files or directories (such as robots.txt) with minimal impact.
- Bugs in non-common browsers or browsers not supported by Bit2Me.
- MITM attacks that require physical access to a user's device.
- Any physical attack against Bit2me properties or its data centers.
- Login panels accessible by public.
- UX or usability problems that do not imply security failures
- Problems with no impact on security (for example, failure to load a page).
- Social engineering, phishing, vishing, smishing against Bit2Me employees, suppliers, clients or users.
- Vulnerabilities already known to us or already reported by someone (the reward will go to the first informant).
How to report a bug?
Send your report to email:
You have to use the following PGP public key to encrypt the email:
Include as many pieces of evidence as possible: 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 did it. It is mandatory to include an explanation on how to correct the reported vulnerability
Please wait up to 10 business days in order our team to study your request and receive an answer on whether we have accepted your request. If accepted, the reward will be paid within the stipulated period in the Response Policy (* see response policy).
Bit2Me will always do everything possible to follow the following policy of response to the requests sent by hackers who participate in our program:
Our maximum time for responses on accepting 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 take days or even weeks.
Payments can be made in different ways:
- Cryptocurrencies: We love cryptocurrencies and if you also like them, it will be a pleasure to pay you the reward in cryptocurrencies such as Bitcoin, Ethereum, Monero or others.
The rewards given by Bit2Me range from € 50 for low vulnerabilities to € 5,000 for highly critical ones.
Normal rewards will be managed based on our vulnerability criticality criteria.
For vulnerabilities that, from the company's internal cybersecurity team, we consider VERY critical, Bit2Me has a special reward of € 5,000.
Note: If the report does not include a valid PoC (proof of concept), the reward rating will be decided according to the reproducibility and severity of the vulnerability, and the amount of the reward may be significantly reduced.
Examples of vulnerabilities we look for:
- XSS (excluding self-XSS).
- CSRF (excluding CSRF that involve actions without impact).
- Remote Code Execution.
- Authentication Bypass.
- SQL Injection.
- Sensitive information leakage.
- LFI / RFI.
- Privilege Escalation.
- Vulnerabilities that may cause loss of funds or assets of the user.
- Vulnerabilities that can cause the leakage of confidential company data remotely.
Hall of Fame
All those people, or entities, that report vulnerabilities and rewarded will be published, if they wish.
Be the first to appear here!
Until the present day, these are the members who have reported an approved 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
- Mayank Sahu
- Kartik Singh
- Niket Popat
Did you find it helpful?
Sorry we couldn't be helpful. Help us improve this article with your feedback.