Hackday (not to be confused with ‘hackathon’ events) is a live event where a group or groups of hackers do security testing to some target (i.e. hack the target). Usually the target is a web application or for example some IoT device. The event may last from one day to a few days. It is common that the organizer will pay bounties for the security vulnerabilities reported by the participants. Organizer(s) can coax hackers to participate with some amazing swag, bounties or other prices that can be won in the event. Bigger the prices, the more hackers will want to join and more experienced hackers will be participating.

The usual flow of the event will be; registering of participants, informational meetup to all, hacking and reporting of vulnerabilities, end meetup and some networking at the end.

This document aims to guide organizers to create and amazing hacking event so everyone participating will have amazing time! Organizer will get the target tested for vulnerabilities and will get good PR from the event.

Target(s)

• If possible, use a testing/staging environment for the Hackday, with extended logging to catch more data in case errors occur (and to avoid causing trouble in Production).
• Permitting hackers to access the log data can help them to dig up issues that lie deep in the application.
• Define the scope of the target in detail. This is hugely important for fair game and equal opportunity for all the teams. And also to safeguard production systems from being hammered.
• Benchmark the system for heavy loads (e.g high amount of requests/queries). Testing can impact availability especially when multiple teams are trying to break it simultaneously.
• In some cases it can be beneficial to allow reconnaissance and testing prior to the event for more value from the event itself, at the risk of low volume of reports in the event itself.
• Prepare user specific or at least team specific set of credentials for the target system. If the permission system is multi-tiered, create at least one user for each user role for each of the testers or teams. Two separate user accounts are necessary for testing certain issues.
• Consider disabling or limiting the use of external security controls such as WAF (Web Application Firewalls) and/or IPS (Intrusion Prevention Systems). This allows the teams to spend time more efficiently on finding vulnerabilities rather than trying to bypass the controls, which can be bypassed by a motivated attacker in the production anyway.

Facilities

• Prepare a room for each of the teams. This will allow the testers to openly communicate about the application and potential vulnerabilities without having to worry about the competing team overhearing the strategy.
• Connectivity options for wired and wireless networks in case one of the options is suffering poor availability.
• Reserve some snacks, refreshing beverages and arrange a quick lunch/dinner depending on the length of the event.

Rewards

• When announcing the event, include what kind of bounties will be available and if monetary, how much is reserved and how it will be paid out to the hackers. This will be the main attraction for many great hackers.
• Explain how you’ll be paying the bounties, whether it is by vulnerability type or by points earned from reporting the vulnerabilities.
• Preferably pay bounties based on business impact instead of vulnerability types. Bug Bounty programs are a great way to find the necessary details.
• If possible, reward each attending hacker/team regardless of their possible findings. This will help hackers cut their travel expenses and motivate them to to try harder next time. The reward can also be some kind of tech gift that is appealing to technically oriented people.
• Prepare the Swag! (great publicity for the company)
  • Stickers/T-Shirts/Hoodies/Backpacks/other

Acknowledgement

• Give warm thanks to your friendly neighborhood hackers. They spend hours travelling to your event to help you secure the target system and to challenge themselves while doing so.
• Don’t underestimate the public “thank you!”. Praise the teams in social media (or other), they will be grateful for it!
• Decide if the best finding/most vulnerabilities/most severe/etc vulnerability will be awarded somehow. This could also increase competitiveness between groups and at least give positive feeling of appreciation to winning group / person.
• Engage in one on one conversations with the participants to establish rapport.

Rules and Reporting

• Non-Disclosure Agreement (reasonable terms).
• Rules
  • Define what happens if a group breaks the rules, e.g. going out-of-scope, disturb other groups, unethical behaviour in the event etc.
  • Out-Of-Scope vulnerabilities should be accepted, but only as informational vulnerabilities in the event and without any points. More value for the money.
  • Malicious intent should be defined in the agreement.
  • Rules, non-disclosure agreements etc. documentation should preferably be sent beforehand for the participants to read.
  • Remember to inform that participants can not share information about the vulnerabilities publicly (or they may lose the bounty for that vulnerability).
• You should define what kind of vulnerability reports will not be rewarded.
• When and how will bounties be paid.
• Ask for consent before unleashing your media team on hackers for surprise photoshoots.
• Allow teams to see reported vulnerabilities (at least the subject of each report) so hackers know not to spend time on duplicate vulnerabilities that will be disqualified.
• Explain what is and what isn’t a duplicate report to avoid confusion.
• Require a definition of impact and a working POC (Proof of Concept) for each reported vulnerability so that the issue is easily reproduced.
• Consider if you want to ban or limit the use of automated scanners. They can help find vulnerabilities but can also negatively affect the system and event by generating excessive amount of traffic.
• Inform teams that all confidential material such as vulnerability details should be removed from hacker’s devices before leaving the event.
• Be prepared to make judgement and decisions swiftly on the spot. Have a clear jury/judge who can make decisions.

Schedule

• Time used to test the target application will of course affect the test coverage. In general, minimum of eight (8) hours should be reserved for testing.
• At the start of the event, go through the rules and specify what is in scope.

Other

• Identify (drivers license or other) each attending hacker.
• Collect bank account details (if applies) for bounty payments.
• Prepare a reporting platform for handling vulnerability reports.
• Consider allowing internet access to hackers so they can access more resources (e.g ad-hoc research).
• It is recommended to have technically inclined staff (developers) and a product owner on site to answer questions and help the jury evaluating vulnerability impact.
• The event must have jury which will decide and evaluate severity and impact of each vulnerability and the possible bounty sum.
• Assist students and/or newbies by guiding them and getting them to know “seniors”. Attract more experienced hackers to teach the juniors with some small reward.
• When the event ends, kill the connections to the target, this way you can be sure that no one tests anymore.

• Jarmon loistava raportti Blind XSS:stä LähiTapiolalle: https://hackerone.com/reports/159498
• Jarmon haastattelu Bugcrowd Bug Bounty alustalla: https://blog.bugcrowd.com/researcher-spotlight-putsi
• Jarkon artikkeli siitä miten valvontakamera otetaan haltuun: https://blog.rot.fi/2017/02/17/tp-link-tl-sc3171g-ip-camera-r00t/
• Iiron seminaariesitys Tesla Motorsin lähdekoodin saamisesta: https://www.youtube.com/watch?v=2a8EgCeBOzw
• Jaken artikkeli mobiililaitteen liikenteen kaappamisesta ja analysoinnista: https://blog.rot.fi/2017/02/07/decomposing-lan-security-with-scapy-and-burp-suite/

Team Rot tarjoutuu käyttämään 15h/henkilö/kohde kunnan järjestelmien teknisen tietoturvan tutkimiseen. Havaitut ongelmat raportoidaan kunnan määrittelemälle henkilölle, yleensä siis tietoturvasta vastaavalle. Tämän lisäksi Team Rot ilmoittaa havainnoista myös Viestintäviraston kyberturvallisuuskeskukselle, CERT-FI:lle joka avustaa tarvittaessa esimerkiksi koordinoinnin kanssa jos haavoittuvuus koskee kunnan ulkopuolisia organisaatioita tai vaikkapa ulkoiselta toimittajalta ostettua ohjelmistoa. Kun raportoidut havainnot on korjattu, niin Team Rot julkistaa niistä yhteenvedon. Yhteenveto käydään ennen julkistamista lävitse yhdessä kunnan kanssa ja sisällöstä poistetaan tarvittaessa esimerkiksi luottamukselliset tiedot.
Havaittujen haavoittuvuuksien kokonaismäärä voidaan julkaista ennen varsinaista ongelman korjaamista, mutta haavoittuvuuksien tarkempia tietoja ja osallistuvaa kuntaa ei julkaista vielä tässä vaiheessa.
Jotta tietoturvatarkastus olisi mahdollisimman sujuva ja reilu kummallekin osapuolelle, niin kunta voi määritellä itse halutun kohteen ja esimerkiksi rajata tietynlaiset testitapaukset pois tarkastuksesta. Team Rot kuitenkin suosittelee että kohteena olisi kaikki kunnan järjestelmät, jotka ovat saatavissa julkisessa verkossa. Näin ollen kunta hyötyy Team Rotin tekemästä työstä mahdollisimman paljon. Team Rot pyrkii olemaan aiheuttamatta minkäänlaista ongelmaa kohdejärjestelmän saatavuuden, eheyden ja luottamuksellisuuden kanssa testauksen aikana.
Mikäli kiinnostuit, ota yhteyttä niin sovitaan jatkosta ja muista mahdollisista velvoitteista.
Sähköpostilla: team@rot.fi
< Iiro Uusitalo
< Jarkko Vesiluoma
< Jarmo Puttonen
< Jake-Matti Lahtinen