Ob Sicherheitsforscher:in oder Gelegenheitshacker:in, wer eine Sicherheitslücke in einer Anwendung oder Webseite findet, steht oft vor der Frage: Was mache ich jetzt?

Wenn wir einen Penetrationstest durchführen, ist die Antwort meist relativ einfach: Wir dokumentieren die Schwachstelle und senden den Bericht nach Abschluss des Projekts an unseren Kunden. Aber wie gehen wir vor, wenn wir eine Sicherheitslücke finden, ohne einen expliziten Auftrag zu haben?

Grundsätzlich gibt es bei dem Umgang mit Schwachstellen mehrere Interessen, die berücksichtigt werden sollten:

• Der Anbieter der Software hat ein Reputationsrisiko durch die Schwachstelle.
• Die Entwickler:innen benötigen Zeit, um die Schwachstelle nachzustellen und zu beheben.
• Nutzer:innen der Software benötigen ggf. Zeit, um Updates zu installieren.
• Betroffene der Schwachstelle haben ein Interesse daran, dass die Schwachstelle behoben wird und sie über das Risiko, dem sie ausgesetzt waren, informiert werden.

Auch der/die Entdecker:in der Schwachstelle hat eigene Interessen. Du kennst am besten deine persönlichen Motivationen, aber häufig treiben Sicherheitsforscher:innen Geld, Anerkennung oder das Gefühl an, das Internet durch ihre Arbeit sicherer gemacht zu haben.

Je nach Situation wiegt das ein oder andere Interesse schwerer. Als guter Weg, die Interessen unter einen Hut zu bringen, hat sich die Vorgehensweise Responsible Disclosure (oder Coordinated Vulnerability Disclosure) bewährt.

Während des Testens

Es ist verständlich, dass du neugierig bist, wenn du eine Schwachstelle entdeckst und die Auswirkungen erkunden möchtest. Aber sei vorsichtig! Das Ausnutzen einer Schwachstelle kann schnell zu rechtlichen und moralischen Problemen führen. Es lohnt sich daher, nach dem ersten Verdacht einen Moment innezuhalten und sich zu überlegen, wie man die Auswirkungen einer Schwachstelle verantwortungsbewusst einschätzen kann.

Gibt es ein Bug-Bounty-Programm für die betroffene Anwendung? In den Teilnahmebedingungen steht normalerweise, was als akzeptables Verhalten gilt und was nicht. Wenn die Schwachstelle in einer Software entdeckt wurde, ist es ratsam, eine Testinstallation aufzusetzen, in der du die Schwachstelle sicher erkunden kannst. Bei Webanwendungen ist das meist schwieriger, aber auch hier gibt es Möglichkeiten, negative Auswirkungen zu minimieren. Vermeide jegliche Handlungen, bei denen du einen Schaden erwartest. Der Zugriff auf Daten anderer Benutzer ist in jedem Fall tabu! Auch wenn es verlockend sein kann, einen funktionierenden Proof of Concept oder sogar ein Exploit zu haben, reicht im Zweifelsfall oft schon ein begründeter Verdacht, um eine Schwachstelle zu melden.

Es ist wichtig, dass du dokumentierst, wie du vorgegangen bist. Dies hilft nicht nur beim Beheben der Schwachstelle, sondern dient auch als Beweis dafür, dass du nicht in böser Absicht gehandelt hast. Zudem erlaubt es auch deinen Ansprechpartnern, deine Schritte nachzuvollziehen und zu verstehen.

Das Melden der Schwachstelle

Nachdem du die Schwachstelle dokumentiert hast, stellt sich die Frage, wie du sie melden kannst. Dafür ist es notwendig, ein wenig Recherche zu betreiben. Manche Firmen und Organisationen haben zentrale Anlaufstellen, an die du Meldungen über ihre Produkte senden kannst. Beispiele hierfür sind Microsoft und Apache. Andere Möglichkeiten, die richtigen Ansprechpartner zu finden, sind eine SECURITY.md im Repository von Open-Source-Projekten oder eine security.txt bei Webseiten oder Webservices.

Wichtiger Hinweis: Wenn die betroffene Software oder Webseite von einem Bug-Bounty-Programm abgedeckt ist und die Schwachstelle darüber gemeldet wird, gelten die für das Bug-Bounty-Programm festgesetzten Regeln. Das bedeutet in den meisten Fällen Private Disclosure, d. h. die Veröffentlichung von Informationen über die Schwachstelle obliegt vollständig dem Softwareanbieter.

Wenn all dies nicht hilft, gibt es noch weitere Optionen: z. B. die Kontaktkanäle im Impressum der Webseite oder Tickets im Bugtracker des Projekts. Beachte jedoch, dass solche Kanäle in der Regel nicht vertraulich sind. Deshalb sollte eine Meldung über einen dieser Kanäle keine Details über die entdeckte Schwachstelle enthalten. Ein einfacher Hinweis, dass es sich um eine Schwachstelle handelt und du gerne den Kontakt zu den Verantwortlichen herstellen würdest, reicht zunächst aus.

Spätestens jetzt ist auch der richtige Augenblick, dir Gedanken zu machen, ob du die Schwachstelle unter deinem Klarnamen oder unter einem Pseudonym melden willst. In der Regel sind die Ansprechpartner:innen dankbar für deine Meldung, aber in manchen Fällen kommt es bei einer Eskalation vor, dass ein Anbieter versucht, den/die Überbringer:in der Nachricht (also dich) als Schuldige:n auszumachen. Wenn du initial unter deinem Klarnamen auftrittst, kannst du dich später nicht mehr umentscheiden.

Das Warten

Nachdem du eine Schwachstelle gemeldet hast, heißt es erst einmal abzuwarten. Wenn keine Reaktion kommt, kannst du nach ein paar Tagen noch einmal nachfragen. Vielleicht hast du den/die falsche:n Ansprechpartner:in erwischt oder er/sie ist im Urlaub. In diesem Fall kannst du es über eine:n andere:n Ansprechpartner:in erneut versuchen.

Irgendwann sollte sich hoffentlich jemand bei dir melden. Wenn es Fragen zur gemeldeten Schwachstelle gibt, könnten Rückfragen kommen. Ansonsten solltest du hoffentlich eine Rückmeldung erhalten, dass die Schwachstelle geschlossen wurde oder ein Feedback darüber, warum dies nicht möglich war. Sobald der Kontakt hergestellt ist, ist es auch der richtige Zeitpunkt, über die Veröffentlichung der Schwachstelle zu sprechen und wann diese stattfinden soll.

Eskalation

Aber was kann man tun, wenn niemand antwortet? Zunächst solltest du noch einmal sicherstellen, dass du den/die richtige:n Ansprechpartner:in gefunden hast. Wenn auch das nicht hilft, kannst du eine Frist setzen, nach der du die Schwachstelle einseitig veröffentlichst, um den Druck zu erhöhen.

Bei der Veröffentlichung sollte es keinesfalls darum gehen, den Anbieter bloßzustellen. Zwar sollte die Veröffentlichung natürlich einen gewissen Handlungsdruck aufbauen, aber primär ermöglicht sie den Nutzern:innen der betroffenen Anwendung, eine eigene Risikoabwägung vorzunehmen.

Es ist schwierig, eine allgemeingültige Frist für die Veröffentlichung einer Schwachstelle festzulegen. Ein guter Richtwert ist beispielsweise 90 Tage. Je nachdem, wie viel Zeit seit der ersten Meldung vergangen ist, kann diese verkürzt werden. Der Anbieter sollte jedoch in jedem Fall ausreichend Zeit haben, um auf die Schwachstelle zu reagieren. In manchen Fällen, zum Beispiel wenn eine Schwachstelle bereits aktiv ausgenutzt wird, kann auch eine deutlich kürzere Frist sinnvoll sein.

Ein paar wichtige Punkte, die du beachten solltest:

• Leider kommt es immer wieder vor, dass ein Anbieter anstatt die Schwachstelle zu beheben, rechtliche Schritte androht oder sogar ergreift. Das ist nicht der gewünschte Verlauf, aber es passiert. Bevor du eskalierst, solltest du noch einmal sicherstellen, dass du dein Vorgehen dokumentiert hast.
• Veröffentliche keine Informationen über die Schwachstelle, bevor die gesetzte Frist abgelaufen ist, auch keine Teaser. Es besteht die Gefahr, dass die Schwachstelle unangemessen aufgebauscht wird.
• Gib dem Anbieter ausreichend Zeit um auf deine Nachricht zu reagieren.
• Vermeide es, die Schwachstelle unnötig aufzubauschen. Von Außen ist es oft schwierig, eine realistische Einschätzung der Schwachstelle zu geben, und die Zusammenarbeit wird erschwert, wenn sich der Anbieter oder die Entwickler:innen zu Unrecht angegriffen fühlen.

Disclosure

Irgendwann sollte die Schwachstelle hoffentlich behoben sein und du möchtest die Informationen über die Schwachstelle veröffentlichen.

Wie der Name Coordinated Vulnerability Disclosure (koordinierte Offenlegung von Schwachstellen) schon andeutet, sollte die Veröffentlichung idealerweise in Absprache mit dem Anbieter der Software erfolgen. Halte dich an getroffene Absprachen, aber das bedeutet nicht, dass du jede Bedingung akzeptieren musst.

Hast du dem Anbieter eine Frist gesetzt, die jetzt abgelaufen ist, musst du dich für ein geeignetes Vorgehen für ein Full Disclosure entscheiden. Bedenke dabei, dass deine Glaubwürdigkeit leidet, wenn du dich von Frust oder Unmut leiten lässt, weil keiner auf deine Anfrage reagiert hat. Versuche, in deiner Veröffentlichung so professionell wie möglich zu sein. Und beim nächsten Mal widmest du deine Forschung den Produkten von kooperativeren Anbietern.

Wie du die Schwachstelle veröffentlichst, ist dir überlassen. Du kannst sie als Blog-Post, Bug-Ticket oder auf einer Mailingliste veröffentlichen. Wenn du bisher darauf geachtet hast, anonym zu bleiben, solltest du auch bei der Veröffentlichung darauf achten. Wenn du die Schwachstelle nicht selbst veröffentlichen möchtest, kannst du auch einen Mittelsmann oder eine Mittelsfrau dafür nutzen. Mögliche Mittelsleute sind Journalist:innen oder andere IT-Sicherheitsexpert:innen, wie wir. In jedem Fall solltest du den Mittelsmann oder die Mittelsfrau aber frühzeitig einbeziehen.

Die Informationen, die du über die Schwachstelle veröffentlichst, sollten detailliert genug sein, damit ein:e Leser:in die Glaubwürdigkeit des Berichts und mögliche Konsequenzen einschätzen kann. Wenn es noch keinen Patch gibt, solltest du mit funktionsfähigen oder fast funktionsfähigen Exploits vorsichtig sein. Das Ziel der Veröffentlichung sollte immer der Schutz der Nutzer sein.

Wenn die Schwachstelle in einer Software auftritt, kann ihr eine CVE ID (Common Vulnerabilities and Exposures) zugeordnet werden, um das Sprechen über sie zu erleichtern. Einige Hersteller, wie z.B. Apache, werden die CVE ID beantragen, wenn sie deinen Bericht akzeptieren. Falls dies nicht der Fall ist, kannst du selbst eine CVE ID beantragen.