Reverse Engineering für Schwachstellenforschung: Was legal ist und was nicht
Dies ist eine der folgenreichsten Grauzonen in diesem Feld, und sie leichtfertig zu behandeln ist ein echtes Risiko, nicht nur eine Formalität.
Was allgemein eindeutig in Ordnung ist
Deine eigene Software zu testen, oder Software, für die du explizite schriftliche Autorisierung zum Testen hast, ist die sichere Standardwahl. Alles wird bedeutend riskanter außerhalb dieser Grenze.
- Dein eigener Code oder deine Systeme — niemandes fremde Rechte sind betroffen.
- Ein autorisierter Penetrationstest oder eine Sicherheitsbewertung mit einer unterschriebenen Umfangsvereinbarung.
- Ein Bug-Bounty-Programm, streng innerhalb seines definierten Umfangs — die meisten großen Programme (über Plattformen wie HackerOne oder Bugcrowd) veröffentlichen genaue Regeln darüber, was im und außerhalb des Umfangs liegt, und diese Regeln zu befolgen ist, was den rechtlichen sicheren Hafen bietet.
Was allgemein eindeutig nicht in Ordnung ist
- Kommerzielle Software per Reverse Engineering speziell zu untersuchen, um Lizenzierung, DRM, oder Paywalls zu umgehen.
- Produktionssysteme oder Software zu testen, die du nicht besitzt und für die du keine Autorisierung zum Testen hast, selbst "nur um zu sehen".
- Ein System nach dem Finden einer Schwachstelle weiter zu untersuchen, über das hinaus, was zum Demonstrieren und Melden nötig ist (dies kann von Forschung zu unautorisiertem Zugriff übergehen).
- Eine Schwachstelle öffentlich offenzulegen, bevor dem Anbieter angemessene Zeit zur Behebung gegeben wurde, wo dies die Offenlegungsbedingungen des anwendbaren Programms verletzt.
Die Grauzonen, die Leute stolpern lassen
- Lizenzvereinbarungen, die Reverse Engineering vollständig verbieten — manche Rechtsprechungen und Kontexte erlauben Reverse Engineering für Interoperabilität oder Sicherheitsforschung trotz solcher Klauseln (dies variiert erheblich nach Land und Kontext); andere nicht. Dies ist wirklich rechtsprechungsabhängig und es lohnt sich, es zu prüfen, statt in die eine oder andere Richtung anzunehmen.
- Eine Schwachstelle außerhalb des angegebenen Umfangs eines Programms zu finden, während innerhalb davon getestet wird — melde sie verantwortungsvoll, aber verstehe, dass du möglicherweise nicht denselben rechtlichen Schutz hast, den das Testen im Umfang bot.
- Ein System zu testen, für das du einst autorisiert warst, aber nicht mehr bist (die Systeme eines ehemaligen Arbeitgebers, zum Beispiel) — eine abgelaufene Autorisierung überträgt sich nicht weiter.
Eine praktische Checkliste vor Beginn jeder Schwachstellenforschung
- Hast du eine explizite, aktuelle Autorisierung für dieses spezifische Ziel?
- Falls es ein Bug-Bounty-Programm ist, liegt das, was du vorhast, innerhalb seines veröffentlichten Umfangs?
- Hast du einen Plan für verantwortungsvolle Offenlegung, falls du etwas findest?
- Bist du bereit, bei "gefunden und demonstriert" aufzuhören, statt weiter nach zusätzlichem Zugriff zu forschen?
Nichts davon ist Rechtsberatung für deine spezifische Situation — Gesetze variieren erheblich nach Rechtsprechung und die Details zählen. Wenn du dir wirklich unsicher bist, ob ein Ziel oder eine Aktivität autorisiert ist, ist die sicherere Standardwahl, nicht fortzufahren, bis du es geklärt hast.
Häufige Fragen
Ist es legal, Software per Reverse Engineering auf Sicherheitslücken zu untersuchen?
Es hängt stark von der Rechtsprechung, den Lizenzbedingungen der Software, und ob du eine explizite Autorisierung hast (wie der definierte Umfang eines Bug-Bounty-Programms) ab. Es gibt keine einzelne globale Antwort — prüfe die spezifischen Bedingungen und das Recht, die für deine Situation gelten, bevor du beginnst.
Macht ein Bug-Bounty-Programm Reverse Engineering automatisch legal?
Es autorisiert Aktivität innerhalb des spezifisch definierten Umfangs dieses Programms — Tests außerhalb des angegebenen Umfangs, oder gegen nicht abgedeckte Systeme/Versionen, sind nicht automatisch geschützt, nur weil das Unternehmen allgemein ein Bug-Bounty-Programm betreibt.
Was ist 'verantwortungsvolle Offenlegung' und warum zählt sie rechtlich und ethisch?
Es ist die Praxis, eine gefundene Schwachstelle privat dem betroffenen Anbieter zu melden und ihm angemessene Zeit zur Behebung zu geben, bevor irgendeine öffentliche Offenlegung erfolgt — dies ist sowohl die ethische Norm in der Sicherheitsforschung als auch, in vielen Bug-Bounty-Bedingungen, eine Voraussetzung für den angebotenen rechtlichen sicheren Hafen.