BTFS (BitTorrent File System) looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.
Response Targets
BTFS will make the best effort to meet the following SLAs for hackers participating in our program:
| Type of Response | SLA in business days |
|---|
| First Response | 5 days |
| Time to Triage | 10 days |
| Time to Bounty | 14 days |
| Time to Resolution | depends on severity and complexity |
We’ll try to keep you informed about our progress throughout the process.
Disclosure Policy
Program Rules
- Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
- When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
- Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
- Social engineering (e.g. phishing, vishing, smishing) is prohibited.
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.
Test Plan
BTFS Setup & Documentation
- Please refer to https://docs.btfs.io/docs for general documentation and setup guides.
- Please ONLY use testnet for your work, instructions here: https://docs.btfs.io/docs/testnet-setup
- Please test against the latest master branch of go-btfs project if possible. When testing, use
btfs config profile apply storage-host-dev to simulate a testnet host, and btfs config profile apply storage-client-dev to simulate a testnet renter.
- Please test BTFS related vulnerabilities in Bittorrent windows client http://download-new.utorrent.com/uuid/241259d7-cef4-400b-a04d-4852c1d585f2.
Scope
Out of Scope for BTFS
- Any (development) branch other than release and master for go-btfs.
- Any branch other than the latest release for all other valid repositories.
- https://docs.btfs.io or any wording on the site (feel free to contribute).
- Any bug/vulnerability relate to bittorrent.com domain.
- Any bug/vulnerability that originates from upstream IPFS projects (https://github.com/ipfs).
- Any bug/vulnerability that impacts TRON blockchain or sidechains. (please submit a bug under https://hackerone.com/tronfoundation instead).
- Any bug/vulnerability of Bittorrent client's own vulnerability which is not related to BTFS.
- Any item in the general Out of Scope section.
Bounty Guidelines/Examples
- Critical
- Arbitrary remote code execution on a BTFS node through the use of BTFS protocol and HTTP APIs.
- Arbitrary access to private datastore on a remote BTFS node.
- Private key leakage and/or loss of funds through BTFS operations.
- High
- Denial of Service (DoS) attack on BTFS network through libp2p protocol.
- Denial of Service (DoS) attack on BTFS network through HTTP API.
- Gaining control or significant influence over centralized service decisions including but not limited to BTFS Escrow, Guard, and Hub.
- Operations or feasible strategies to disrupt a fair peer-to-peer storage network by becoming malicious nodes.
- Medium
- Unauthorized operations on behalf of a BTFS user that does not incur a loss of funds.
- Throttling or significantly reducing BTFS network performance involving either peer-to-peer or centralized components.
- Bypassing permissions to access non-critical but sensitive user data.
- Low
- General bugs that can be triggered to prevent users from fairly participating in BTFS network, or running stable nodes.
- Attacks to influence network states and user decisions on storage parameters.
- Enabling remote nodes to perform non-essential operations without their consent.
- Public key leaks or unauthorized access to non-BTFS node components, including officially-backed community components (severity up to impact and team decision).
Submission Requirements
- Summary of the bug/vulnerability
- Steps to reproduce
- Working Proof of Concept
- Impact is based on, but not limited to the following:
* How easy is it to find the vulnerability?
* How likely is it getting exploited? Would the economic incentive make sense?
* [If it has already been exploited] How much impact does it make on a decentralized network? How big is the range of parties affected?
* Is any private user data exposed?
* Is any private financial data affected?
Out of scope vulnerabilities
When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) security impact of the bug. The following issues are considered out of scope:
- Clickjacking on pages with no sensitive actions
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Attacks requiring MITM or physical access to a user's device.
- Previously 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.
- 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.
- Missing HttpOnly or Secure flags on cookies
- 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 (e.g. stack traces, application or server errors).
- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
- Tabnabbing
- Open redirect - unless an additional security impact can be demonstrated
- Issues that require unlikely user interaction
Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Thank you for helping keep the BTFS network and our users safe!