Bug-Bounty-Programme – Strafbarkeit des Suchens nach Sicherheitslücken

Suche nach Sicherheitslücken, Strafbarkeit und Bug-Bounty-Programme: Hierbei handelt es sich um Aufrufe von Anbietern dahin, 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 durchaus Vorsicht geboten. Insbesondere bei einem „aufgedrängten“ Bug Bounty stehen erhebliche strafrechtliche Risiken im Raum – und auch die erwünschte Suche nach Sicherheitslücken geht mit eigenen Pflichten einher!

Zivilrechtliches Verständnis von Bug-Bounty-Programmen

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 Paragrafen. 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 Tester 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.

Strafrechtlicher Blick auf Bug Bounty Programme

Strafrechtlich ist es auf den ersten Blick bei einem Bug-Bounty-Programm 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.

Möglicher strafrechtlicher Hintergrund

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 Log-in-ID für die eigene Session kreieren.

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 tatbestandsausschließendes 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 tatbestandsausschließendes Einverständnis angenommen. Das aber nur am Rande.

Vorsicht, verschätzen Sie sich nicht! Die Suche nach Sicherheitslücken, gleich, ob von der anderen Seite erwünscht oder von Ihnen aufgedrängt, hat erhebliche rechtliche Bedeutung!

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 auch mit den Beispielen: Das Einverständnis hat jedenfalls Grenzen und dessen müssen sich probier freudige Hacker und Script-Kiddies im Klaren sein. Wer die Grenzen des Einverständnisses verlässt, handelt nämlich plötzlich schon wieder unbefugt und damit strafbar im Sinne des § 202a I StGB.

Reichweite des Einverständnisses bei Bug Bounty

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.

„Aufgedrängtes“ Bug-Bounty – Strafbarkeit der Suche nach Sicherheitslücken

Ganz besonderes Augenmerk verdient die Frage des Umgangs mit einem „aufgedrängten“ Bug-Bounty: Jemand findet, vielleicht zufällig, vielleicht auch mit zielgerichteter Suche, eine Sicherheitslücke. Und jetzt? Viele wenden sich an den Verantwortlichen, in der Hoffnung auf Anerkennung oder Geld; manche veröffentlichen im Frust über ein Ignorieren hinterher die Sicherheitslücke – und wundern sich dann, wenn die Polizei vor der Türe steht.

Eigenes Rechtsverständnis

Das Problem bei ITlern ist nach meinem Eindruck, aus meinen Verfahren, dass ein sehr eigenes Verständnis und ein – nicht zuletzt durch Online-Foren geprägtes – verzerrtes Bild der juristischen Lage existiert. So glaubt man, etwas Gutes zu tun und ist vollkommen blind dafür, dass das eigene „Ehrempfinden“ rein gar nichts damit zu tun hat, dass man Gefährdungslagen schafft. Und natürlich ist eine nicht behobene Sicherheitslücke eine erhebliche Gefahr, gerade bei verbreiteter Software oder Hardware – hier aber setzt eine Abwägung ein, wer blindwütig Sicherheitslücken kommuniziert, begeht einen Fehler.

Nicht nur juristisch, auch in der IT-Sicherheit gibt es gerade keinen Grundsatz, dass man Sicherheitslücken sofort allgemein zur Verfügung stellt. Und alle Diskussion dazu, dass unsere Fehlerkultur in Deutschland nicht innovationsfördernd ist, mag durchaus zutreffen – hat aber rein gar nichts mit den nun mal geltenden Gesetzen zu tun.

Pflichten beim Auffinden einer Sicherheitslücke

Andersherum wird ein Schuh daraus: Wenn man eine Lücke gefunden hat und kein offizielles Bug-Bounty-Programm angeboten hat, treffen den Entdecker (wenn er nicht in einem Rechtsverhältnis zum Betroffenen steht) keine grundsätzlichen Pflichten, er darf das ignorieren. Bevor er irgendetwas an Dritte trägt, wird er – entsprechend den Grundsätzen des Whistleblowings – sich immer zuerst an den Betroffenen wenden müssen. Sollte er dies getan haben und es passiert nichts, wird er im nächsten Schritt wohl Fachpresse und Behörden, speziell aber allem voran das BSI, informieren können.

Auch sollte man niemals darauf hoffen, im Streitfall vor einem Richter zu sitzen, damit dieser Verständnis aufbringt dafür, dass man aus eigenem Affektionsinteresse gerade nicht die Presse informiert hat, sondern über Foren dafür sorgte, dass massiver Schaden entstehen kann. Schon alleine das Streuen der Sicherheitslücke kann dabei zivilrechtliche Ansprüche auslösen!

Strafrechtliche Relevanz

Ob zudem eine strafrechtliche Relevanz vorliegt, lässt sich nur im Einzelfall beurteilen. Vielfach gehen nach meinem Eindruck Ermittler von einem Ausspähen von Daten (§ 202a StGB) aus, obwohl es schon an der besonderen Sicherung gerade fehlen wird. Auch ist die schlichte Suche nach Sicherheitslücken gerade nicht strafbar, wie ich immer mal bei Gericht klarstellen muss. Speziell bei zufällig gefundenen Sicherheitslücken wird sich alleine durch das Finden der Lücke kaum eine Strafbarkeit ergeben; anders dagegen, wenn man zielgerichtet gesucht hat, hier kann nur die pauschale Formel geboten werden, dass je komplexer die Lücke oder das Ausnutzen der Lücke, je eher eine theoretische Strafbarkeit im Raum stehen wird.

Datenschutzrechtliche Problematik der Suche nach Sicherheitslücken

Erheblich komplexer ist es datenschutzrechtlich mit Bug-Bounty-Programmen: Sollte man im Rahmen des Bug-Bounty Aufrufs einen Bug finden und hierdurch personenbezogene Daten Dritter betroffen sein, so entsteht aus meiner Sicht zumindest eine Meldepflicht an den Betreiber des Programms. Man hat also nicht mehr die Wahl, ob man sich beim Anbieter meldet, sondern muss offenlegen, was man „erreicht“ hat und welche Daten zumindest betroffen waren. Ein Speichern derartiger Daten ist in jedem Fall zu unterlassen, selbst Screenshots mit entsprechenden Daten würde ich kritisch sehen. Insoweit dürfte nichts anderes gelten als bei einem ordentlich beauftragten Pentest, nur eben entsprechend.

Fazit: Vorsicht mit der laienhaften Suche nach Sicherheitslücken und Bug-Bounty

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. Umso mehr bei einem „aufgedrängten“ Bug-Bounty, mit dem man mit einem Bein immer in der Strafbarkeit steht. Die Ausformulierung entsprechender Texte darf dabei keineswegs übers Knie gebrochen werden. Die Nutzer dagegen sind auf der anderen Seite gut beraten, nicht einfach aus Langeweile herumzuprobieren und insbesondere von einem Ausprobieren abzusehen, wenn man selber noch kein Semiprofessionelles Stadium als Entwickler erreicht hat.

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.

• Über
• Letzte Artikel

Rechtsanwalt Jens Ferner (Fachanwalt für IT- & Strafrecht)

Fachanwalt für Strafrecht & IT-Recht bei Anwaltskanzlei Ferner Alsdorf

Ich bin Fachanwalt für Strafrecht + Fachanwalt für IT-Recht und widme mich beruflich ganz der Tätigkeit als Strafverteidiger und dem IT-Recht. Vor meinem Leben als Anwalt war ich Softwareentwickler. Ich bin Autor sowohl in einem renommierten StPO-Kommentar als auch in Fachzeitschriften. Dabei bin ich fortgebildet in Krisenkommunikation und Compliance.

Erreichbarkeit: Per Mail, Rückruf, Threema oder Whatsapp.

Unsere Kanzlei ist spezialisiert auf Starke Strafverteidigung, seriöses Wirtschaftsstrafrecht und anspruchsvolles IT-Recht + Kunst & Medien - ergänzt um Arbeitsrecht.

Letzte Artikel von Rechtsanwalt Jens Ferner (Fachanwalt für IT- & Strafrecht) (Alle anzeigen)

• Captagon im deutschen Strafrecht: Ein Überblick - 8. Oktober 2024
• Perfctl: Neue, heimtückische Malware, die Millionen von Linux-Servern bedroht - 7. Oktober 2024
• Datenschutzverstöße durch E-Mail-Weiterleitung: Haftungsrisiken für Geschäftsführer - 6. Oktober 2024