FLOSSHack for Organizers

FLOSSHack is designed as an event and competition that brings together aspiring "breakers" and open source software that could use a hand in securing their software.

Selecting a Target

An ideal target application for a FLOSSHack event has the following properties:

• Open source -- It is critical for newbies to have the source code available while trying to learn about flaws
• Is a "worthy" project -- Preferably a project that wouldn't otherwise be able to afford a security audit
• Is currently maintained -- It does little benefit to a project to find vulnerabilities that no one will fix
• Has a cooperative maintainer -- Support from a software maintainer in running the event can really help things run smoothly
• Is an "up and coming" project -- A relatively new project with a quickly growing user base; more likely to be immature code and will benefit the most people

It may be difficult to satisfy all of these properties, but hopefully this provides some guidance. Note that it is helpful to poll your OWASP chapter for ideas on software targets or what general technologies they are interested in learning more about. See a rough list of possible FLOSSHack Candidates.

Overview of Event Timeline

• 3-4 weeks prior to workshop: FLOSSHack event schedule announced. Software platform/technologies can be mentioned, but do not name the target software yet.
• 1 week prior to workshop: Kickoff the competition. Name the target software, provide all materials needed for testing
• 7-5 days before workshop: Hold a breakers training session
• Workshop: 3-4 hour hack session

Preparation

Communicate with maintainers

Before investing too much time in holding the event, make sure that the target software maintainer is on board with the event and can support you in organizing it. Establish a few ground rules:

• How can the maintainer help you? Can they provide a virtual machine with the software preinstalled? What version of the software is best targeted?
• Are there specific deployment scenarios that are more "typical" or "interesting" to attack? What is the application's authorization model?
• Can the maintainer join the workshop session, either physically or remotely, to help answer questions?
• How will vulnerabilities be communicated to the maintainer? Is there a secured bug tracker available that will keep flaws hidden until fixed?
• Would the maintainer be willing to provide prizes of some sort to the winners of the competition?

Line up venues

Obviously, some sort of venue will be needed to gather people together for the breaker training session as well as the workshop. Consider providing some refreshments for the workshop, since it will be long.

Determine competition prizes

Consider offering at least two prizes for:

• Finder of the "best" bug, as voted on by participants
• Finder of the most bugs

Prizes could be funded by a sponsor or the target software maintainer. Failing that, perhaps draw on OWASP chapter funds. Prizes do not need to be significant/expensive. Just a little icing on the cake beyond the bragging rights.

Make it easy for hackers: provide all materials

When the target software is announced and the competition is kicked off, be sure to provide materials to make it easy for breakers to get started with their audit. If the software isn't super easy to install (or even if it is), try to provide a virtual machine for download with the software pre-installed. If this isn't possible (perhaps due to OS licensing reasons), perhaps a public installation of the software could be provided that everyone could bang on. Of course the source code should be provided at the same time, along with any useful documentation. Remember, some breakers may not be very experienced or know the particular technology platform very well, so try to make it easy.

Note that it is recommended that a designated OWASP wiki page or something similar be set up to distribute information about the competition and all materials.

Breakers training session

A central goal of FLOSSHack is to help less experienced programmers and security people learn more about the nuts and bolts of application security testing. However, FLOSSHack is also a hacking competition, which tends to draw more experienced breakers. For this reason, it is helpful to have a special session, held early in the week of the competition, to help less experienced folks learn about the kinds of flaws they should be looking for. To this end, try to set up a 1-2 hour session of talks, discussion, or labs that explain how certain classes of vulnerabilities work. A hacking tutorial of sorts. The types of vulnerabilities discussed should be ones that are likely to be found in the target application. However, don't discuss specific flaws of the target application, lest you make it unfair to others that can't attend the training session.

Set up remote access

It may be worthwhile to offer remote access to the hacking session for those who can't make it in person. In FLOSSHack One, we initially tried using G+ Hangouts for this, but it turned out to be difficult to organize, so we fell back to a simple IRC channel. Online meeting services or just a simple phone conference bridge could work as well.

Competition and Workshop

The hacking competition should start about a week before workshop day, and conclude at the end of the workshop. If participants find vulnerabilities prior to the workshop, they should send details to the organizer so they get first credit for the flaw. Throughout the competition, participants should be encouraged not to publish details of any flaws found until after the maintainer has a chance to fix the issue. The workshop itself will run something like this:

1. The organizer calls on participants share any vulnerabilities found prior to the workshop. Participants briefly describe their bugs and how they could be exploited. Open discussion is encouraged.
2. Collaborative hacking begins
3. Occasionally, when participants spot new vulnerabilities they should announce it and describe the bug to others. The resulting discussion may spark new ideas for finding additional flaws. (If things are "slow" in this area, the FLOSSHack organizer or other experts may stop everyone once in a while to cover some security topic that may help in further bug finding.)
4. Conclude the workshop session with, hopefully, a pile of security bugs. Organizers can give a summary of the bugs found and then award prizes through voting or whatever process was established for the awards.

Follow Up

The organizer compiles all security flaws found during the competition and sends them to the application maintainers. If any deeper technical questions arise, the organizer directs those questions to the original discoverer of the flaw. Organizers should try to encourage or facilitate the assignment of CVE identifiers for each flaw, and the individual bug discoverers should get credit for them (unless they want to remain anonymous). After specific issues are rectified and published in a new version of the target software, organizers should publish them to the event's wiki page or some other central location. Keep in mind, aspiring pentesters may find it a very useful benefit to have CVEs in their name in order to build their resumes, so be sure credit is given where it is due.