Viele Unternehmen haben erste Gehversuche mit sogenannten Bug-Bounties gemacht. Freiwillige Researcher sollen dafür entlöhnt werden, wenn sie Schwachstellen in Komponenten finden und diese melden. Verlockend ist die Idee, dass man weitestgehend auf regelmässige Security Tests verzichten kann und stattdessen nur noch pro Finding auszahlen muss. Dieser Beitrag diskutiert, wann eine Bug-Bounty sinnvoll ist, wie sie angegangen werden muss und welche Herausforderungen gegeben sind.

Bei einer Bug-Bounty sollen freiwillige Researcher mit einer Entlöhnung motiviert werden, Schwachstellen in Komponenten zu finden und frühzeitig zu melden. Dadurch sollen konkret exponierte Schwachstellen schnellstmöglich entdeckt und adressiert werden können, um das Zeitfenster für erfolgreiche Angriffe auf ein Minimum zu reduzieren. Um eine Bug-Bounty professionell und effizient durchführen zu können, gilt es gewisse Aspekte auszuarbeiten, zu dokumentieren und öffentlich bereitzustellen.

Scope eingrenzen

Grundsätzlich muss man sich darauf einigen, welchen Scope eine Bug-Bounty abdecken soll. Hier ist es einem freigestellt, welche Abrenzungen man etablieren will. Viele Firmen definieren sämtliche öffentlichen erreichbaren Systeme. Andere fokussieren sich auf einzelne Services und klammern bestimmte Komponenten vollumfänglich aus.

Die Abgrenzung kann aber auch in der Form von konkreten Angriffstechniken erfolgen. Viele Bug-Bounties schliessen zum Beispiel destruktive Angriffe, bei denen eine Überlastung angestrebt wird, aus. Dazu gehören unter anderem klassische Flooding-Zugriffe, wie sie bei Denial of Service-Attacken genutzt werden.

Das Definieren eines möglichst breitflächigen Scopes lässt natürlich den Vorteil einer Bug-Bounty vollumfänglich entfalten. Man muss sich aber bewusst sein, dass eine Bug-Bounty auch immer ein Mehr an Testern motiviert. Es ist also konkret damit zu rechnen, dass die im Scope enthaltenen Komponenten einem Mehr an Zugriffen, Stress und Angriffen ausgesetzt sind.

Das ist auch einer der Gründe, warum DoS- und DDoS-Angriffe in der Regel ausgeschlossen werden. Dabei handelt es sich meist um David gegen Goliath-Angriffe, bei denen früher oder später der Stärkere gewinnen wird. Dieses offensichtliche Konzept im Rahmen einer Bug-Bounty zu beweisen bringt keinen Mehrwert und stört stattdessen nur den regulären Betrieb.

Einige Hersteller schränken die für eine Bug-Bounty zugelassenen Teilnehmer ein. So wird bei Apple nur entlöhnt, wer zu dessen produktspezifischem Bug-Bounty-Programm zuvor eingeladen wurde. Bei sogenanntem Invite-Only handelt es sich um einen fragwürdigen Ansatz, vermag er nämlich ein Grossteil der potentiellen Teilnehmer nicht zu motivieren.

Belohnungen definieren

Die Motivation für Researcher, sich mit einer Bug-Bounty auseinanderzusetzen, ist in den meisten Fällen die Bounty selbst. Schliesslich wollen sie für ihre Mühen entlöhnt werden. Aus diesem Grund ist es wichtig zu definieren und klar zu kommunizieren, welche Belohnungen zur Verfügung stehen. In den Anfangszeiten des Konzepts von Bug-Bounties wurden bedruckte Kaffeetassen und T-Shirts vergeben. Derlei Möglichkeiten können heutzutage nur noch ergänzend eingesetzt werden, müssen nämlich mittlerweile monetäre Anreize in Aussicht gestellt werden, um Researcher zu motivieren.

Je höher eine Entlöhnung ist, desto eher sind Tester bereit, ihre Zeit zu investieren, um qualitativ hochwertige Schwachstellen zu finden. Ein transparentes Preiskonstrukt hilft allen Seiten, klare und faire Verhältnisse zu schaffen. Grundsätzlich gibt es Preisbereiche für einzelne Server, Dienste oder Mechanismen. Traditionell werden darin Abstufungen für einzelne Schwachstellenklassen definiert. Ein fehlender HTTP-Header, der theoretisch eine Information Disclosure ermöglicht, wird da natürlich ganz anders eingestuft als eine SQL-Injection oder eine Memory Corruption. Hier kann auch ein Modell wie CVSS (Common Vulnerability Scoring System) beigezogen werden. Durch das Erstellen eines Vektors für eine Schwachstelle lässt sich der Base Score ermitteln und anhand dessen den Preis ableiten.

Bei Bug-Bounties von Herstellern ist es wichtig, dass die Preise möglichst hoch sind. So kann verhindert werden, dass die gefundenen Schwachstellen stattdessen durch eine Ausnutzung oder den Weiterverkauf monetarisiert werden. Bei Bug-Bounties von produktiven Umgebungen ist dies teilweise vergleichbar. Auch hier sollte die Entlöhnung natürlich hoch genug sein, so dass sich ein böswilliges Ausnutzen nicht lohnt. Vor allem bei sehr kritischen Problemen, die eine ganzheitliche Kompromittierung ermöglichen können, sollte nicht gespart werden.

Das Auszahlen der Bug-Bounties kann sich manchmal schwieriger gestalten, als angenommen. Gerade wenn die Researcher in fremden Ländern sitzen und dort das Bankwesen nicht oder nur teilweise etabliert wurde. So ist es dann auch nicht unüblich, dass in solchen Fällen die Auszahlungen über Paypal oder gar Bitcoin umgesetzt werden. Man sollte sich früh damit auseinandersetzen, welche Zahlungsmechanismen man unterstützen will. Auch hier hilft eine klare Kommunikation in der Definition der Bug-Bounty.

Kommunikationskanal festlegen

Die Bug-Bounty kann auf der öffentlichen Webseite als solche ausgeschrieben werden. Dadurch ist sie einfach und unkompliziert durch die Interessenten erreichbar.

In RFC 9116 wird ein simples Dateiformat definiert, dass das Anbieten von Bug-Bounties und das Etablieren von Kommunikationskanälen vereinheitlichen und vereinfachen soll. So soll auf einem Webserver eine Textdatei unter /.well-known/security.txt abgelegt werden, die die folgenden Informationen beinhalten kann:

Eine simple security.txt, so wird sie bei uns eingesetzt, kann also so aussehen:

Contact: mailto:info@scip.ch
Contact: https://www.scip.ch/?contact
Expires: 2023-09-30T23:59:59.000Z
Acknowledgments: https://www.scip.ch/?bugbounty
Policy: https://www.scip.ch/?bugbounty
Hiring: https://www.scip.ch/?jobs
Preferred-Languages: en, de

Ein einfacher Kommunikationskanal wird bevorzugt, weshalb in erster Linie eine herkömmliche Kommunikation per Email zu etablieren ist. Kontaktformulare auf Webseiten können ebenso genutzt werden, wobei diese möglichst simpel gehalten werden sollten (keine Anmeldung erforderlich, nur wenige Felder). Eine verschlüsselte Kommunikation dank PGP ist empfohlen.

Prozesse etablieren

Es muss, gerade in der Anfangszeit nach edem Aufschalten der Bug-Bounty, mit einer gewissen Anzahl an Submissions gerechnet werden. Manche Security Researcher sind auf der Suche nach neu eröffneten Bug-Bounties und versuchen als erste mögliche Schwachstellen zu finden. Diese werden entsprechend über den etablierten Kommunikationskanal gemeldet. Die Abarbeitung gestaltet sich dann wie folgt:

1. Bestätigen des Empfangs der Submission
2. Plausibilisierung der Submission (sind die richtigen Komponenten getestet worden, klingen die Schwachstellen plausibel)
3. Weitere Details beim Submitter erfragen, falls erforderlich (z.B. Exploit, Video des Angriffs)
4. Weiterleiten und technisches Nachvollziehen der Schwachstellen
5. Bewerten der Schwachstelle (Priorität, Kritikalität)
6. Gegenmassnahmen planen, einleiten, umsetzen und prüfen
7. Akzeptieren oder Zurückweisen der Schwachstelle an den Submitter
8. Transaktion der Belohnung vorbereiten (Zahlungsmethode, Zahlungsinformationen)
9. Übermitteln der Belohnung und Hinzufügen des Submitters in die Hall of Fame
10. Lessons Learned in den neuen Prozess einfliessen und dokumentieren lassen

Wie bei allen Prozessen sollten diese formalisiert und dokumentiert werden. Dadurch lässt sich gewährleisten, dass auch bei einem hohen Datenaufkommen und engen Zeitplänen der korrekte Ablauf und mit ihr die erwartete Qualität gewährleistet werden kann.

Es besteht die Möglichkeit diese Abarbeitung an ein externes Bug-Bounty-Programm auszulagern. Verschiedene Firmen weltweit, auch solche in der Schweiz, bieten derlei Dienstleistungen im kommerziellen Bereich an. Man kann dabei von ihren Erfahrungen und etablierten Prozessen profitieren. Selbstverständlich fallen hierbei jedoch zusätzliche Kosten an. Eine Alternative ist das offene Projekt OpenBugBounty.

Generell ist es ein Problem, wenn viele falsche, fehlerhafte oder ungenaue Submissions bearbeitet werden müssen. Es ist nicht unüblich, dass gewisse Security Researcher durch automatisierte Skripte einfache Schwachstellen finden und von diesen Profitieren wollen. Solche Low Hanging Fruits werden oft aus dem Scope genommen und ihr minimales Risiko wird akzeptiert. Dazu gehört zum Beispiel oftsmal das Akzeptieren von älteren Kommunikationsverschlüsselungen oder die vielen HTTP-Security-Header. Dennoch übergehen manche Security Researcher diese Vorgaben und generieren durch die unnötigen Submissions ein Mehr an Aufwand.

Nicht selten arten solche schwachen Submissions in sogenannte Beg Bounties aus: Die Submitter betteln darum, dass ihre Eingabe dennoch berücksichtigt und ausgezahlt wird. Hier empfiehlt es sich das Scoping sehr konsequent zu dokumentieren und auch durchzusetzen. Wer eine gute Submission macht, soll fair entlöhnt werden. Und wer sich nicht an die Regeln hält, muss mit Einschränkungen rechnen. In extremen Fällen können Submitter geblacklisted und vom Programm ausgeschlossen werden.

Um ein hohes Aufkommen an Submissions möglich effizient abarbeiten zu können, sollte für jeden Kommunikationsschritt entsprechende Templates ausgearbeitet werden. Diese lassen schnell und unkompliziert den aktuellen Stand oder die nächsten Schritte mitteilen.

Fazit

Bug-Bounties klingen verlockend. Schliesslich muss man einfach ein paar Regeln definieren und kann dann von der Freiwilligkeit etwaiger Spezialisten profitieren. Dies ist aber nur bedingt korrekt. Die meisten Security Researcher, die sich auf Bug-Bounties spezialisiert haben, wollen mit möglichst wenig Aufwand möglichst viel Umsatz machen. Das Nutzen von Automatisierungen und das Fokussieren auf möglichst simple Schwachstellen ist dann im Fokus. Entsprechend ist ein absoluter Grossteil der Submissions von schlechter Qualität. Erfahrungsgemäss sind 99% der Submissions falsch oder minderwertig. Diese müssen dennoch bearbeitet und koordiniert werden. Entsprechend kann man nur von wenigen wirklich guten Submissions profitieren.

Zudem ersetzt eine Bug-Bounty keine anderen Sicherheitsmassnahmen. Informationssicherheit beginnt mit sicherer Entwicklung und wird gestützt durch professionelles Security Testing. Das Etablieren von Bug-Bounties ist ein Zusatz, der erst ganz am Schluss berücksichtigt werden soll. Andernfalls wird ein Bug-Bounty-Programm teurer und aufwändiger weder der Einsatz der etablieren Mechanismen. Wer sich als erstes und ausschliesslich auf Bug-Bounties verlässt, ist schlecht beraten.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://www.cobalt.io/blog/the-history-of-bug-bounty-programs
• https://www.openbugbounty.org
• https://www.rfc-editor.org/rfc/rfc9116
• https://www.scip.ch/.well-known/security.txt
• https://www.theverge.com/2016/8/4/12380036/apple-bug-bounty-program-vulnerability-security
• https://www.troyhunt.com/beg-bounties/