H1-213 Notice

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!

What's Up with the PRs and Dupe Period?

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:

1. Find a security bug.
2. Submit a HackerOne report.
3. Fix the code on your own system. We recommend posting a diff into the HackerOne report.
4. Contact @flyingtoasters or @zom_snack to say you fixed the code and have a PR ready.
5. The Triage team and Bug Bounty team will work with the Moloch team to review the bug (US East coast business hours, 9a-5p) and ticket internally as necessary.
6. The Bug Bounty team will tell you to submit the PR. Make sure you record a link to it in the HackerOne report.
7. The Moloch team and the Bug Bounty team will review the PR and decide how best to fix the bug.
8. Your PR will be accepted or rejected.
9. The bug will be fixed; code will be pushed to GitHub and the *.test.molo.ch servers will be updated.

Notes:

• The Dupe Period will be cut off somewhere between: [during step 5] to [before step 7].
• If you deviate from this path, we do not guarantee the dupe-split will be locked appropriately.
• The Paranoids’ teams are actively reviewing H1 reports and PRs in git so we can lock the dupe period for related reports appropriately.
• While you have a PR open, be available via Slack. The Moloch team might want to reach out to you to edit your PR if it is close enough to their selected solution. If you miss this opportunity, you may only receive a partial bonus or nothing.

PR FAQ

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 PRs or Best 10 PRs get 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...?

1. Person A submits a bug.
2. Person B submits a dupe.
3. 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:

• If the fix is accepted, the HackerOne report submitters (A+B) would split the bounty but the PR submitter (only the one that was accepted) would earn the bonus (B). By this point the HackerOne report (or group of reports) will be locked and not accepting new dupes to split the bounty.
• If the fix is rejected, the submitter (A, B, or C) will earn nothing.
• If the fix is on the right path, but the dev team decides for a larger fix instead, the submitter (A, B or C) will earn a partial bonus (amount TBD likely 10%).

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 Period short 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).

About Athenz

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.

About Moloch

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