Phase I: April 1st - May 7th, 2019
- Hackers submit a Request to Participate
- All verified hackers will advance to Phase II
Phase II: May 7th - 21st, 2019
- All approved hackers will be given a list of penetration tests and the necessary credentials to access the in-scope elements of our platform
- Hackers will choose 1 test from the List of 6 Tests to conduct and submit preliminary findings
- Up to 5 Finalists will be selected to advance to Phase III
Phase III: May 28th - June 11th, 2019
- The 5 Finalists will be eligible to conduct the remaining 5 tests from the List of Tests, and complete list of approved penetration tests in-scope with the Challenge
- Hackers will submit all final deliverables including all detected, in-scope platform vulnerabilities
- HeroX will award Finalists $50 - $1,500 per vulnerability detected, according to the Prize Structure below
At the conclusion of Phase III, HeroX will award $50 – $1,500 per vulnerability according to the technical severity listed below. There is a $5,000 maximum reward per Finalist.
- Priority 1 Critical $1,000 - 1,500
- Priority 2 High $500 - $800
- Priority 3 Medium $100 - $200
- Priority 4 Low $50 - $100
For the initial prioritization of findings, please refer to our Severity Level Definitions, below. In some cases, our internal judges may modify a vulnerability rating due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority.
Severity Level Definitions
Critical severity issues present a direct and immediate risk to a broad array of our users or to HeroX itself. They often affect relatively low-level/foundational components in one of our application stacks or infrastructure. For example:
- Access to sensitive production user data or access to internal production systems.
- Bypassing the HeroX login process, either password or 2FA.
- Arbitrary SQL queries on the HeroX production database.
- Arbitrary code/command execution on a HeroX server in our production network.
High severity issues allow an attacker to read or modify highly sensitive data that they are not authorized to access. They are generally more narrow in scope than critical issues, though they may still grant an attacker extensive access. For example:
- Gaining access to a non-critical resource that only HeroX employees should be able to reach.
- Discovering sensitive user or HeroX data in a publicly exposed resource, such as an S3 bucket.
- Bypassing authorization logic to grant a repository collaborator more access than intended.
- Injecting attacker controlled content into HeroX.com (XSS) which bypasses CSP.
Medium severity issues allow an attacker to read or modify limited amounts of data that they are not authorized to access. They generally grant access to less sensitive information than high severity issues. For example:
- Bypassing CSRF validation for low risk actions, such as starring a repository or unsubscribing from a mailing list.Code execution in a desktop app that requires no user interaction.
- Injecting attacker controlled content into HeroX.com (XSS) but not bypassing CSP or executing sensitive actions with another user’s session.
- Disclosing the title of issues in private repositories which should be inaccessible.
Low severity issues allow an attacker to access extremely limited amounts of data. They may violate an expectation for how something is intended to work, but it allows nearly no escalation of privilege or ability to trigger unintended behavior by an attacker. For example:
- Triggering application exceptions that could affect many HeroX users.
- Triggering verbose or debug error pages without proof of exploitability or obtaining sensitive information.
- Bypassing community-and-safety features such as locked conversations.
- Creating an issue comment that bypasses our image proxying filter by providing a malformed URL.
- Signing up arbitrary users for access to an “early access feature” without their consent.
List of Tests
- Cross-Site Scripting (XSS)
- SQL Injection
- Sensitive Data Exposure
- Broken Access Control
- Security Misconfiguration
- Broken Authentication
For more information about these tests, please visit OWASP's Guide, here.
Scope of this Challenge
- What computer assets are in scope for the test?
- HeroX.com website and its infrastructure
- Does it include all computers, just a certain application or service, certain OS platforms, or mobile devices and cloud services?
- All computers and services related to HeroX.com website.
- Does the scope include just a certain type of computer asset, such as web servers, SQL servers, all computers at a host OS level, and are network devices included?
- Everything is included.
- Can the pen testing include automated vulnerability scanning?
- Is social engineering allowed, and if so, what methods?
- What dates will pen testing be allowed on?
- The Challenge Launch Date is April 1st, 2019 and the Submission Deadline is June 11th, 2019. During this window, pen testing will be allowed anytime according to the Challenge Structure outlined above.
- Are there any days or hours when penetration testing should not be tried (to avoid any unintentional outages or service interruptions)?
- No. Penetration Testing is allowed any time from April 1st, 2019 - June 11th, 2019.
- Should the professional attackers (e.g., red team) try to break-in without being detected by the defenders (e.g., blue team), or should they use normal methods that real intruders might use to see if it sets off existing detection and prevention defenses?
- No. These interruptions are a crucial part of the pen test.
- Will the penetration testing be blackbox (meaning the pen tester has little to no internal details of the involved systems or applications) or whitebox (meaning they have internal knowledge of the attacked systems, possibly up and involving relevant source code)?
- Should testers try their best to avoid causing service interruptions or is causing any sort of problem a real attacker can do, including service interruptions, a crucial part of the test?
- Use normal methods that real intruders might use to see if it sets off existing detection and prevention methods. Include all attempted (but defended) and successful attacks in your documentation.
- Is denial-of-service considered an in-scope goal?
- DoS (Denial of Service): Yes, in-scope
- DDoS (Distributed Denial of Service): No, out of scope
- Is accessing a particular computer or exfiltrating data part of the goal, or is simply gaining privileged access enough?
- The goal is to access any data that the user should not be able to access or to gain any additional access.