Note: Verizon Media is now known as Yahoo.
This has been a wild ride over the past week, and we are so excited to see the energy and engagement that has come with 1) opening up access to our code and 2) submitting PRs to fix your own bugs. The entire thing is new ground for us (if not in general), and we plan to continue to do our best to make sure everyone is reasonably treated and awarded fairly. As part of the quick spin-up to testing out this different format, we have come up with a process change that affects the standard live event `Dupe Period.’ That means there has been some confusion, and we would like to clear that up!
At a live event, typically only the Critical or High reports would receive fixes in advance of the big day (because of the criticality). In this event, we are saying that submitting a PR for your bug means that we will react in the same way as a high/crit (but it does not escalate the severity). All reports will follow the standard dupe-window (closed at the start of the event 11/8), unless they are a High or Critical severity, or there's a PR against them.
If you just want to hack, then just hack like at a typical H1 LHE.
On the other hand, developing a fix (following these steps outlined below) will allow you to lock dupes on your report, and might net you some extra cash from the open source bonuses that we have up for grabs.
The recommended path is:
*.test.molo.ch servers will be updated.Notes:
Dupe Period will be cut off somewhere between: [during step 5] to [before step 7].What if someone introduces a bug with a PR? Should I report it?
If the PR was accepted (and merged), then the bug is fair game and you should file an H1 bug report as well as an updated PR to claim that bonus. If the PR was not accepted, then it never made it into the codebase. Try to write a better fix for that bug than the PR that you saw, then your solution might get accepted and you would earn the bonus.
What happens if I have already submitted a PR and not a report?
Oops. You should submit a HackerOne report immediately, and get in contact with us so we can review it and lock the dupes.
If the team doesn't accept the PR, do we get a chance to write a revision? Suppose there are several possible fixes but I'm not sure what fix the team would prefer.
It depends. Whenever possible, we are definitely looking for fixes that address the class of problems instead of just one local instance. You could note in the PR that you are willing to revise or ping before submitting the PR.
Do the
First 10 PRsorBest 10 PRsget the bonus?
The way bonuses have worked in the past at live events is "the first X people to earn the bonus, get it; person X+1 will receive an 'out of stock' notice." We will evaluate the first or best scenario if and when we get to it. We believe we should lean towards first based on the standard live hacking event structure; that means First 10 PRs that are accepted, and not First 10 PRs that are submitted.
I assume code-related HackerOne reports will be validated when the PR is accepted.
Of course. All reports submitted are silently validated as usual at live events. We're not updating the visible status on any reports until after kickoff on 11/8.
What happens if...?
- Person A submits a bug.
- Person B submits a dupe.
- Person B sends a PR. 4a. (optional) Person C sends a PR. 4b. (optional) Person A sends a PR.
Person B's actions would cause the original report (by Person A) to be locked. We assume that Person A has decided not to submit a PR, or has taken too long to do so. Person A, Person B, and Person C (no related report) could submit a PR to address the original report (by Person A) and would be eligible to claim the bonus.
This would result in the following award scenarios:
What timezone are you working from so we know when best to contact you?
United States East Coast; We are based outside of Washington D.C. -- EST or EDT (depending on the day you read this). Business hours are 9am - 5pm.
How do I cut the
Dupe Periodshort for a bug that I found?
Write a code fix and submit using the process outlined above.
I found a bug and figured out how to fix the code. How do I submit a PR to earn the bonus without allowing the other hackers to just dupe my report as soon as the PR goes online?
Perfect. This is what we want to encourage. Follow the process outlined above and everything should be sunshine and rainbows for you (and a pot of gold).
Regarding Domain Permissions -- https://<ATHENZ_ENDPOINT>/athenz/ajax/domain for example, will show all of the domains, this is by design; once you are authenticated you have access to all the data; the authorization check occurs when you try to make changes. To make things more user friendly, the UI will only show the domains that you are referenced in (that you have permission for), but nothing will stop you from looking at the other domains.
Out of Scope yahoo/athenz/ui, yahoo/athenz/contributions, and yahoo/athenz/docker are outdated from our own internal deployment because of our use of Okta and Duo which we are not able to deploy to you all for this event; this is why we stated the Athenz UI was out of scope during the scoping call. The UI was just given out as a starting point so whoever needs it, can take it, integrate with their own authentication system and also provide all the necessary protections. Our UI devs worked with the Paranoids’ red team internally for quite some time to go through all this, addressing many different types of bug classes with our integration with Okta and Duo and that’s what we’re running in our production instance.
The Moloch team is reviewing all PRs. So far, some have been rejected as partial fixes in favor of their own (in-house) holistic fix. There's also at least one PR that will be accepted (so far).
When you list "Denial of Service attacks" as borderline out of scope / informative, does that include application-level DOS, or only DDOS?
The intention there is to prevent disabling our test hosts, thereby preventing hackers from hacking. DDoS is likely not a useful attack scenario to protect against, because Moloch would be deployed in a private network environment. Application level-DoS on the other hand, e.g. a user can submit a payload that disables moloch, would be a valuable bug. If you are interested in testing, deploy the services on your own to ensure the impact of testing does not touch the other hackers at this event.
Happy Hacking
The Paranoids