Bug-Bounty-Programme: Vorsicht ist geboten!

Inzwischen mehren sich die so genannten “Bug-Bounty-Programme”, aktuell etwa von PayPal. Hierbei handelt es sich um Aufrufe von Anbietern, dass Außenstehende Sicherheitslücken in deren Angeboten aktiv suchen und melden sollen. Es ist also der öffentliche Aufruf, eigene Angebote (wie etwa Webseiten) zu “hacken”. Wer hier eine Sicherheitslücke findet und meldet, wird mit einer Zahlung von Geld “belohnt”. Aber: Es ist Vorsicht geboten.

Zivilrecht: Der Anspruch besteht
Zivilrechtlich sind solche Bug-Bounty-Programme nach deutschem Recht als Auslobung nach §657 BGB bindend. Wichtig für denjenigen, der da auslobt sind dabei die folgenden Paragraphen. So ist ein Ende eines Bug-Bounty-Programms nach deutschem Recht nicht möglich, indem man es einfach einstellt – vielmehr ist ein öffentlicher Widerruf entsprechend §658 BGB notwendig. Besonderes Augenmerk sollte man dabei auf den §659 BGB richten, der vorgibt, dass in dem Fall dass mehrere Erfolg haben, die Belohnung demjenigen gebührt, der als erster erfolgreich war (Absatz 1). Und wenn man mal zeitgleich war (was wohl eher nicht der Fall sein wird, da letztlich auf den Maileingang abzustellen ist und es hier eine zeitgleiche Mail wohl nicht geben wird), wird die Belohnung geteilt oder bei einer unteilbaren Belohnung gelost (§659 II BGB).

Die wesentliche Erkenntnis: Das ist hier kein Versprechen im luftleeren Raum, sondern eine bindende Zusage, die auch eingeklagt werden kann.

Strafrecht…
Strafrechtlich ist es auf den ersten Blick einfach: Da steht ein Aufruf des “Eigentümers” der Seite im Netz, seine Seite zu hacken. Wenn der schon darum bittet, dann kann das doch nicht verboten sein? Im Kern ist das korrekt, es kommt aber auf die Feinheiten an.

Wenn man sich Gedanken über die Strafbarkeit eines “Hacker-Angriffs” auf eine Webseite macht, stehen vor allem die §§202a, 303a StGB im Raum. An dieser Stelle möchte ich mich nicht in eine Analyse verlieren und kurz feststellen, dass meines Erachtens bei einem üblichen “Hacker-Angriff” der §202a I StGB erfüllt sein wird. Der §303a I StGB wird bei den üblichen Hacker-Szenarien jedenfalls dann betroffen sein, wenn irgendwo Daten – auch nur kurzzeitig – verändert werden. Wer es ohne Datenveränderung schafft, vorhandene Daten nur auszulesen, wird hier nicht erfasst sein. Tatsächlich aber muss man im Regelfall zumindest im Arbeitsspeicher des die Webseite bereit stellenden Rechners Daten verändern, etwa eine Login-ID für die eigene Session kreieren. Die durchaus spannende Frage soll aber einem eigenen Artikel vorbehalten bleiben.

Etwas Dogmatik: Schon der Laie sieht bei einem Blick ins Gesetz: Der §202a StGB spricht von einem “unbefugten” Handeln, der §303a I StGB von einem “rechtswidrigen” Handeln. Der reine Wortlaut spricht dafür, dass hier zwei verschiedene Konstrukte vorliegen: Im Fall des §202a I StGB ein sogenanntes tatbestandsausschliessendes Einverständnis, im Fall des §303a I StGB eine rechtfertigende Einwilligung. Der Unterschied ist, dass man bei ersterem schon gar keinen Tatbestand verwirklicht, in zweitem Fall alleine die Rechtswidrigkeit entfällt, aber eine Tatbestandsverwirklichung vorliegt. Tatsächlich aber wird auch beim §303a I StGB im Falle einer Zustimmung zum Handeln ein tatbestandsausschliessendes Einverständnis angenommen. Das aber nur am Rande.

Wichtiger ist, dass man sich genau ansieht, wie die Zustimmung (also das Einverständnis) formuliert ist – hier bieten sich einige Haken an. Denn das Problem ist: Wer sich auf eine Zustimmung berufen möchte, der muss auch grundsätzlich im Rahmen dieser Zustimmung handeln. Und der Blick auf die Erklärungen der Anbieter zeigt, dass “einfach nur rumprobieren” nicht ohne weiteres funktioniert.

Am besten gefällt mir dabei die Erklärung von Google, denn sie bietet praktikable Sicherheit. Dort liest man u.a.:

Q) How far should I go to demonstrate a vulnerability?
A) Please, only ever target your own account or a test account. Never attempt to access anyone else’s data. Do not engage in any activity that bombards Google services with large numbers of requests or large volumes of data.

Es wird also klar gesagt: Man hat einen Testaccount anzulegen und alleine damit zu arbeiten, um Daten anderer Nutzer nicht anzutasten. Das ist eine klare Vorgabe, die man auf Anhieb versteht. Bei PayPal ist es nicht wirklich schwerer zu verstehen, aber schon nicht mehr ganz so klar konturiert:

Do not engage in security research that involves […] Use of an exploit to view another user’s data without their authorization, or to corrupt data.

Das mag auf das gleiche hinauslaufen, aber die Formulierung bei Google, die klar sagt “Lege dir einen eigenen Account an, und arbeite nur damit” gefällt mir einfach besser.

Letztlich zeigt sich hier schon: Das Einverständnis hat jedenfalls Grenzen und dessen müssen sich probierfreudige Hacker und Script-Kiddies im Klaren sein. Wer die grenzen des Einverständnisses verlässt, handelt nämlich ganz schnell schon wieder unbefugt und damit strafbar im Sinne des §202a I StGB.

Die Reichweite des Einverständnisses
Die bisherigen Programme geben sich alle Mühe, möglichst verständlich zu machen, was man darf und was nicht. Im Kern sind es zu erwartende Vorgaben: Zum einen ist ein Abschiessen der Dienste mittels simpler DDOS-Attacken nicht gestattet. Aus technischer Sicht ist dies zu erwarten, da hier keine neue Sicherheitslücke gemeldet werden würde, von der man als Anbieter ernsthaft profitiert. Ansonsten gibt es detaillierte Vorgaben, je nach Anbieter, etwa Logout-Fallen (PayPal) oder social engineering (Google). Dass man bei Google sogar physische Übergriffe ausnimmt zeugt von der Detailverliebtheit der dortigen Juristen.

Die Einschränkungen hinsichtlich der Art des Angriffs und der zu suchenden Sicherheitslücken sind auf den ersten Blick plausibel und alltagstauglich. Was ist aber, wenn jemand zwar nur mit seinem Account arbeitet und (mehr oder minder) versehentlich Zugriff auf Daten anderer User erlangt, etwa wegen einer systemweiten Lücke? Die Google-Erklärung gibt dafür ausdrücklich kein Einverständnis – gleichwohl, jedenfalls wenn je nach Lücke dieser Effekt unvermeidbar war, muss hier das Einverständnis entsprechend ausgelegt und gedeutet werden. Je nach Einzelfall wird sich der Programmierer hier kaum Sorgen machen müssen, gleichwohl sei zur Vorsicht gemahnt, die Einschränkungen ernst zu nehmen.

Interessanter ist die Frage, wie man mit den “erweiterten Vorgaben” umgehen soll. So sind sämtliche Bug-Bounty-Programme ausdrücklich auf White-Hats ausgerichtet und geben mitunter sehr restriktive Vorgaben, wie Sicherheitslücken zu melden sind. Dabei lässt es sich im Kern darauf reduzieren, dass – wie üblich – Sicherheitslücken nicht (direkt) öffentlich zu machen sind und dem Anbieter eine gewisse Reaktionszeit zuzugestehen ist (die natürlich zeitlich nicht eingegrenzt wird). Was ist, wenn man sich entsprechend den Vorgaben verhält, eine wesentliche Lücke findet und meldet, und nach 3 Wochen ohne Reaktion meint, diese nun an die Presse weiterzugeben – war der Angriff dann vom Einverständnis gedeckt oder nicht?

Die Frage ist für mich keinesfalls einfach. Ich denke, wer jedenfalls von Anfang an vor hatte, eine gefundene Lücke ohne Meldung zu veröffentlichen, der wird sich nicht pro forma auf das Einverständnis berufen können. Andersrum wird das Einverständnis nicht daran scheitern, dass man im Detail von den Meldevorgaben abgewichen ist. Letztlich wird es auf den Einzelfall ankommen.

Fazit: Vorsichtig.
Bug-Bounty-Programme sind für Unternehmen bedeutsame Möglichkeiten, um Sicherheitslücken aufzufinden. Wer so etwas einrichtet, muss sich der rechtlichen Relevanz im Klaren sein, sowohl zivil- als auch strafrechtlich. Die Ausformulierung entsprechender Texte darf dabei keineswegs über’s Knie gebrochen werden. Die Nutzer dagegen sind auf der anderen Seite gut beraten, nicht einfach aus Langeweile herumzuprobieren. Dies gilt insbesondere für Script-Kiddies, zumal im Regelfall die Verwendung automatisierter Tools ohnehin untersagt ist. Wer sich im Rahmen eines solchen Programms profilieren möchte, sollte durchaus ein gewisses Vorwissen samt Praxis mitbringen und zielgerichtet vorgehen, dabei die Grenzen des Einverständnisses genau herausarbeiten und exakt befolgen.

mm

Ich bin als Strafverteidiger und Fachanwalt für Informationstechnologierecht speziell im IT-Strafrecht tätig und berate rund um Cybercrime sowie das digitale und Wirtschafts-Strafrecht. Neben dem IT-Recht bin ich vorwiegend im Strafrecht tätig mit inzwischen mehreren hundert Strafverteidigungen. Die Anwaltskanzlei Ferner Alsdorf bietet seit ihrer Gründung vor 20 Jahren eine eindeutig fokussierte Tätigkeit auf das Strafrecht.

One Reply to “Bug-Bounty-Programme: Vorsicht ist geboten!”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.