Find vulnerabilities in TON OS Rust DApp Server components.
Goal is to enhance security of TON OS Rust DApp Server, find and fix security bugs with different severity.
Qualifying Vulnerabilities in TON OS Rust DApp Server
- Bugs in implementation/usage of the cryptographic primitives
- Remote Code Execution on Full Node or Q-Server components
- Leakage of sensitive data
- Vulnerabilities that affect the stability, connectivity, or availability of the Full Node, Kafka, Kafka Conntectors or DataBase components
- Vulnerabilities that affect the stability or availability of the Q-Server
- TON OS Rust DApp Server (repo link) from master branch only
Out of scope
- Non-technical attacks, such as a physical attack, social engineering, phishing, etc.(E.g. HTTP Basic Authentication Phishing)
- Denial-of-Service (due to numerous spam requests or distributed attacks).
- Theoretical vulnerabilities without actual proof of concept
- Vulnerabilities only exploitable on out-of-date browsers or platforms
- Reports from automated tools or scans, without exploitability demonstration
- Use of known vulnerable libraries without actual proof of concept
- Vulnerabilities that require physical access to a user’s device
Requirements on Those Submitting Reports
- You represent that your bug report is your original idea and work product and has not been copied or misappropriated from any third party.
- You will submit bug report only from email or other accounts that you own or with explicit permission of the account holder
- You will not exploit a security, privacy or other issue you discover for any reason. (This includes demonstrating additional impact, such as attempted compromise of sensitive data or probing for additional issues.)
- You will not violate any applicable laws or regulations, including (but not limited to) laws and regulations prohibiting unauthorized access to data or computer systems.
- You will not violate the intellectual property or other rights of any third party.
- You will not attempt to introduce any virus or malicious code into any computer system or data
- Do not Publicly Disclose any vulnerabilities without our consent. We will not approve Public Disclosure requests until the vulnerability has been resolved
Contest Dates: 27 July 2020 — 27 August 2020
1 place — 75 000
2 place — 50 000
3 place — 40 000
4 to 10 — 5 000 each
The places are for cumulative contribution to the Contest.
- Jury should be formed from the community members with high technical knowledge and experience
- Initial members whose team(s) intend to participate in the contest lose their right to nominate a jury member.
- Each Jury will vote by rating each submission on a scale of 0 to 10.
- Jurors must provide short feedback on contestant submissions
An amount equal to 5% of all total tokens actually awarded and distributed will go to each juror for performing their civic duty to the community and taking the time to judge each submission and provide feedback.