Rechtssicherheit Cybersecurity Blog Fraunhofer AISEC

Mehr Rechtssicherheit für White Hat Hacker

Selbst bei größter Sorgfalt sind IT-basierte Systeme und Produkte selten frei von Sicherheitslücken. Damit Schwachstellen und Angriffsflächen frühzeitig entdeckt und behoben werden, müssen Soft- und Hardware rigorosen Sicherheitsprüfungen unterzogen werden. Dabei laufen Cybersicherheitsforschende, die Schwachstellen verantwortungsbewusst und im Sinne des Gemeinwohls melden (so genannte „White Hat Hacker“) aktuell Gefahr, sich strafbar zu machen. Das Fraunhofer-Institut für Angewandte und Integrierte Sicherheit AISEC hat daher anhand von best-practice-Erfahrungen ein internes Vorgehen festgelegt, wie Forschende des Fraunhofer AISEC mit aufgedeckten Schwachstellen umgehen. Außerdem hat das Fraunhofer AISEC gemeinsam mit dem interdisziplinären Forscherteam Sec4Research ein Whitepaper mit Vorschlägen zur Verbesserung der Rechtslage von „White Hat Hackern“ aus der Forschung erarbeitet.

Das Fraunhofer AISEC sieht es als einen gemeinnützigen Auftrag, zur Absicherung von IT-basierten Systemen und Geräten vor Manipulation und Cyberangriffen neben der defensiven Entwicklung von Schutzmechanismen auch offensive Sicherheitsforschung zu betreiben. Das bedeutet, dass Wissenschaftler*innen vorübergehend die Rolle eines Angreifers übernehmen und versuchen, durch sogenannte Penetrationstests Einfallstore in Systemen offen zu legen. So erlangen sie umfassende Kenntnisse über die Funktionsweise der zu schützenden Technologie und sind in der Lage, Schwachstellen auszumachen und Schutzmaßnahmen zu entwerfen, bevor ein krimineller Angreifer die Sicherheitslücken missbraucht.

Auf diese Weise werden im Rahmen von Forschungsarbeiten am Fraunhofer AISEC regelmäßig Sicherheitslücken entdeckt. Umso wichtiger ist es, diese Schwachstellen Herstellern zu melden und ihnen die Möglichkeit zu geben, ihre Produkte abzusichern und Endverbraucher*innen vor Schaden zu bewahren.

Sicherheitsforschende rechtlich auf dünnem Eis

Nach aktueller deutscher Gesetzgebung sind einige Instrumente und Vorgehensweisen, die für das Aufdecken von Schwachstellen und damit für die Arbeit von IT-Sicherheitsforschenden grundlegend sind, gesetzlich verboten.

Beispielsweise werden bei Sicherheitstests mittels Reverse-Engineering systematisch die Funktions- und Konstruktionsweise eines unbekannten Systems oder Produkts ermittelt und auf Fehler untersucht. Gemäß Urheberrecht sind einige Formen des Reverse-Engineerings nur mit Zustimmung der Urheber erlaubt. IT-Systeme bestehen allerdings aus zahlreichen Komponenten unterschiedlicher, internationaler Hersteller. In der Praxis ist es also kaum möglich, die Einwilligung aller Urheber einzuholen. Folglich beinhalten Reverse-Engineering-Tätigkeiten unkalkulierbare Haftungsrisiken auch für Cybersicherheitsforschende, die zudem im Vergleich zu den verantwortlichen Unternehmen über weitaus geringere juristische Ressourcen verfügen.

Coordinated Disclosure Procedures am Fraunhofer AISEC

Mangels rechtlicher Vorgaben hat das Fraunhofer AISEC einen Prozess zur Coordinated Vulnerability Disclosure (CVD) definiert, der festlegt, wie Forschende mit aufgedeckten sicherheitsrelevanten Mängeln umgehen. Dabei werden weder Schwachstellen direkt für Hersteller, Nutzende, andere Forschende, Geheimdienste und Kriminelle vollumfänglich offengelegt (sogenannte Full Disclosure), noch wird ein identifiziertes Sicherheitsrisiko ignoriert oder verharmlost. Ziel ist vielmehr eine Kompromisslösung zugunsten der Nutzenden und Hersteller zu finden, bei welcher der kriminelle Missbrauch des Produktmangels ausgeschlossen und die Sicherheit der Allgemeinheit gewahrt bleibt.

Die Vorgehensweise zur Offenlegung von Schwachstellen gilt ausschließlich solchen, die im Rahmen von Forschungsprojekten des Fraunhofer AISEC oder im Rahmen von öffentlich geförderten Projekten aufgedeckt werden. Sicherheitsbedenken, die bei der Auftragsforschung für Partner aus der Industrie aufkommen, werden ausschließlich den Kunden vertraulich kommuniziert und unterliegen nicht dem Coordinated Vulnerability Disclosure-Prozess des Fraunhofer-Instituts.

Abbildung 1: Coordinated Vulnerability Disclosure am Fraunhofer AISEC 

Schritt 1 und 2: Auffinden und Prüfen der Sicherheitslücke

Wurde eine sicherheitsrelevante Schwachstelle im Rahmen der Eigenforschung des Fraunhofer AISEC aufgefunden, wird diese intern dokumentiert und geprüft, ob sie bereits in der CVE-Datenbank (Common Vulnerabilities and Exposures, www.cve.org) gelistet und damit bekannt ist. Zusätzlich wird ein institutsinternes Ethik-Review-Board einbezogen, dem Expertinnen und Experten der offensiven IT-Sicherheitsforschung des Fraunhofer AISEC angehören. Sie nehmen eine erste vertrauliche Bewertung der Schwere der aufgedeckten Sicherheitslücke vor und stehen den Forschenden sowie der Institutsleitung bei der Kommunikation mit den Produktverantwortlichen beratend zur Seite.

Schritt 3: Meldung an Verantwortliche

Ist die entdeckte Schwachstelle sicherheitsrelevant, aber trotzdem noch nicht öffentlich bekannt, werden im nächsten Schritt die verantwortlichen Produkthersteller über den Sicherheitsmangel in Kenntnis gesetzt. Eine solche Meldung erfolgt – wenn möglich – in Kombination mit einem konkreten Lösungsansatz, der beschreibt, wie negative Auswirkungen der Schwachstelle abgewendet werden können.

Gleichzeitig reserviert das Fraunhofer AISEC ohne konkrete Angaben zum Sicherheitsrisiko eine ID-Nummer in der CVE-Datenbank der MITRE Corporation. Ist der verantwortliche Hersteller selbst eine CNA (CVE Numbering Authority) – also einer der IT-Anbieter, Sicherheitsfirmen oder Forschungseinrichtungen, die neben der MITRE Corporation CVE-Nummern ausgeben und verwalten – wird die Schwachstelle gemeldet, indem die Sicherheitslücke in der Datenbank des verwaltenden Herstellers registriert wird.

Bedauerlicherweise haben nur wenige Hersteller etablierte Abläufe zur Entgegenahme von Sicherheitsmängeln gemäß ISO-Standard 30111 »Prozesse für die Behandlung von Schwachstellen«, sodass sich für Forschende bereits die Suche nach zuständigen sowie fachlich kompetenten Ansprechpartner*innen und die verschlüsselte Übermittlung von sicherheitskritischen Informationen zur Schwachstelle als schwierig gestalten können. Wir empfehlen Herstellern dringend solche Meldungsportale und die zugehörigen Prozesse einzurichten. Hierbei beraten wir gerne.

Leichter ist es bei Lücken, die in Open-Source-Projekten aufgedeckt werden. Hier ist es in der Regel einfacher, in direkten Kontakt mit den Entwickler*innen der Software zu treten und diese über die Mängel zu informieren. Weiterhin sind keine Strafanzeigen seitens der Urheber zu fürchten.

Schritt 4 und 5: Beseitigung des Sicherheitsmangels und Veröffentlichung

Im Idealfall werden Sicherheitsmängel umgehend durch Hersteller oder Betreiber beseitigt. Anschließend publiziert das Fraunhofer AISEC in Zusammenarbeit mit dem Hersteller Informationen zur behobenen Schwachstelle für die Öffentlichkeit in Form eines wissenschaftlichen Papers oder Blog-Beitrags.

Erfolgt jedoch nach der durch das Ethik-Review-Board festgesetzten Frist keinerlei Rückmeldung seitens des Herstellers bzw. ist zu vermuten, dass keine Lösung erarbeitet wird, setzt das Fraunhofer AISEC unter Angabe der jeweiligen CVE-Referenz die Öffentlichkeit über die bestehende Lücke in Kenntnis, damit Nutzer*innen Schutzmaßnahmen ergreifen und Schäden abwenden können.

Ein solcher Prozess der Coordinated bzw. Responsible Vulnerability Disclosure, wie er am Fraunhofer AISEC praktiziert wird, findet im geltenden Rechtsrahmen in Deutschland keine Berücksichtigung. Er ist allerdings nötig, um im Sinne des Gemeinwohl agierende Wissenschaftler*innen von Cyberkriminellen abzugrenzen und Forschungsinstituten die Möglichkeit zu geben, effektiv Schutzmaßnahmen gegen neuartige Angriffe und Sicherheitslücken entwickeln zu können, ohne juristische Konsequenzen befürchten zu müssen.

Reformbedarf in Gesetzgebung zu offensiver Sicherheitsforschung

Um auf die Lücke in der Gesetzgebung aufmerksam zu machen und Sicherheitsforschenden eine aus juristischer Sicht bedenkenlose Offenlegung von Schwachstellen zu ermöglichen, hat sich das Fraunhofer AISEC dem interdisziplinären Forscherteam Sec4Research angeschlossen. Das 2021 gemeinsam erarbeitete Whitepaper beleuchtet die aktuelle Rechtslage für das Auffinden und Melden von Sicherheitslücken. Die 22 Autor*innen fordern darin Rechtssicherheit in der IT-Sicherheitsforschung, klare Standards im Umgang mit Sicherheitslücken, internationale Kooperationen und ein deutliches Bekenntnis seitens der Politik zur Cybersicherheitsforschung.

Handlungsempfehlungen des Fraunhofer AISEC

Ergänzend zum Whitepaper legt das Fraunhofer AISEC drei konkrete Handlungsempfehlungen vor, um deutschlandweit eine rechtskonforme, verantwortungsbewusste Offenlegung von Schwachstellen zum Schutz von Betroffenen zu ermöglichen und die Sicherheit von IT-basierten Systemen und Produkten zu erhöhen:

  • Legalisierung von Reverse-Engineering in Software: Im Gegensatz zum Zerlegen und Analysieren von Hardware verbieten Lizenzbedingungen von Software bisher meist jegliche Versuche, Software auf ihre Bestandteile und deren Beziehungen zueinander zu untersuchen. Dies schränkt die Möglichkeiten stark ein, Sicherheitslücken aufzudecken und Nutzende zu schützen.
  • Entwicklung einer unabhängigen Meldestelle: Um IT-Sicherheitsforschenden die Möglichkeit zu geben, sich klar von Cyberkriminellen abzugrenzen und ihre guten Absichten für das Gemeinwohl aufzuzeigen, bedarf es einer unabhängigen Meldestelle für sicherheitskritische Findings, die koordiniert und dokumentiert, ob und wann Hersteller über eine Schwachstelle in ihrem Produkt in Kenntnis gesetzt wurden.
  • Aufbau einer Service-Organisation: Neben der Rechtsunsicherheit herrscht zwischen ethischen Hackern und den Herstellern oder Betreibern anfälliger Produkte ein deutliches Ungleichgewicht. Nach dem Vorbild der französischen Initiative »Cybersecurity Advisors Network« (CyAN) (de) kann eine unabhängige Organisation mit Beratungsleistungen und Rechtsbeistand für »White-Hat-Hacker« Abhilfe schaffen. Zudem könnte eine solche Stelle einen Austausch mit großen Konzernen auf Augenhöhe ermöglichen und für die Interessen von ethischen Hackern auf politischer Ebene einstehen.

Ziel von Politik, Gesellschaft sowie Herstellern und Betreibern von IT-Systemen muss es sein, Bedingungen zu schaffen, die eine verantwortungsbewusste und koordinierte Offenlegung von IT-Sicherheitslücken ermöglichen, Nutzende und Unternehmen vor Schäden bewahren und Deutschland als Standort für eine international wettbewerbsfähige IT-Sicherheitsforschung erhalten.

Weiterführende Informationen

» Homepage Sec4Research: https://sec4research.de/

» Homepage Fraunhofer AISEC: https://www.aisec.fraunhofer.de/

Autoren
Grau_Logo_Blog_Author
Marc Schink

Marc Schink forscht am Fraunhofer AISEC im Bereich „Hardware Security“. Sowohl am Institut als auch im Privaten befasst er sich damit, Schwachstellen in Hard- und Software aufzufinden. Dabei hat er mehrfach Vulnerability-Disclosure-Prozesse mit namhaften und internationalen Herstellern durchgeführt.

Grau_Logo_Blog_Author
Dieter Schuster

Dieter Schuster ist in der Forschungsabteilung „Product Protection and Industrial Security“ am Fraunhofer AISEC tätig. Er koordiniert den Themenbereich Offensive Security und Penetrationstests.

Most Popular

Keinen Beitrag verpassen?

Bitte geben Sie Ihre E-Mail-Adresse ein, um keinen Blog-Beitrag zu verpassen.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.

* Pflichtfeld

* Pflichtfeld

Mit dem Ausfüllen des Formulars akzeptieren Sie unsere Datenschutzerklärung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Artikel

gallia – ein erweiterbares Framework für Penetrationstests

gallia ist ein erweiterbares Framework für Penetrationstests mit Fokus auf den Automotive-Bereich, das von Fraunhofer AISEC unter der Apache 2.0 Lizenz entwickelt wurde. Der Anwendungsbereich der Toolchain umfasst die Durchführung von Penetrationstests von einem einzelnen Steuergerät bis hin zu ganzen Fahrzeugen. Derzeit liegt der Hauptfokus von Testings auf der UDS-Schnittstelle, ist aber nicht darauf beschränkt.
Der folgende Blogartikel gibt einen Gesamtüberblick über die Architektur von gallia. Er geht auf die Plugin-Schnittstelle sowie den beabsichtigten Automotive-Anwendungsfall ein. Der Beitrag behandelt zudem die Interaktion zwischen einzelnen Komponenten und zeigt, wie gallia für andere Anwendungsfälle erweitert werden kann.

Weiterlesen »

Sicherheitskritische Risiken mit Android App Links

Android App Links ermöglichen die Verknüpfung von Webinhalten mit mobilen Anwendungen. Die bestehenden Systeme weisen jedoch mehrere sicherheitskritische Probleme auf – vor allem drei verschiedene Arten des Link-Hijacking. Bisher gab es kaum Informationen über den Forschungsstand hinsichtlich dieser Sicherheitslücken. Wurden sie bereits behoben und wann? Wie funktionieren unsichere Übertragungswege von Webinhalten zu mobile Anwendungen? Dieser Beitrag informiert über den Stand dieser Probleme und zeigt Wege auf, den Transfer sicherer zu gestalten.

Weiterlesen »

Eine behutsame Einführung in die gitterbasierte Post-Quanten-Kryptografie

In den letzten Jahren wurden erhebliche Fortschritte bei der Erforschung und Entwicklung von Quantencomputern erzielt. Ein voll entwickelter Quantencomputer wird in der Lage sein, eine Reihe von mathematischen Problemen – wie die ganzzahlige Faktorisierung und den diskreten Logarithmus – effizient zu lösen, die die Grundlage für eine Vielzahl von kryptografischen Verfahren bilden. Im Jahr 2016 hat das US-amerikanisch National Institute of Standards and Technology (NIST) einen offenen Wettbewerb ausgeschrieben, mit dem Ziel, geeignete Algorithmen für quantenresistente Kryptografie zu finden und zu standardisieren. Die Standardisierungsbemühungen des NIST streben sichere Post-Quanten-KEMs und digitale Signaturen an. In diesem Artikel werden zwei der zu standardisierenden Algorithmen, Kyber und Dilithium, vorgestellt und einige ihrer mathematischen Details skizziert. Beide Algorithmen basieren auf sogenannten Gittern und dem darauf aufbauenden »Learning with Errors«, die im Artikel näher beleuchtet werden.

Weiterlesen »