GFI: Ist die vollständige Offenlegung von Schwachstellen immer eine gute Idee?
Die Öffentlichkeit fordert heute deutlich mehr Transparenz als in der Vergangenheit – von Regierungsbehörden, börsennotierten Unternehmen, sogar Privatunternehmen und Individuen. Der Ruf nach einer „vollständigen Offenlegung“ kommt aus beiden politischen Richtungen und erstreckt sich über eine Vielzahl von Branchen. Wir wollen Alles über Alles wissen: Absolut geheime Kriegspläne, Geschäftszahlen, was Prominente im Bett tragen (oder nicht) – und welche Sicherheitsschwachstellen in der Computer Software entdeckt wurden.
Vielleicht hat diese Vorliebe für immer weitere Informationen mit dem Aufkommen der 24 Stunden Nachrichtennetzwerken zu tun, das uns ständig mit Fakten und Meinungen (egal ob relevant oder nicht) rund um die Uhr füttert. Was auch immer der Grund ist, es ist zu einer allgemeinen akzeptierten Überzeugung geworden, dass wir das angeborene Recht auf alle Informationen besitzen, die möglicherweise unser Leben in irgendeiner Weise beeinflussen können – und selbst auf diejenigen Informationen, die das nicht machen.
In diesem Sinne sind einige IT-Sicherheitsforscher der Meinung, dass die IT-Sicherheit im Interesse der Nutzer ein „Recht auf Wissen“ beinhaltet und entsprechend werden Informationen über Software-Schwachstellen sofort nach ihrer Entdeckung publiziert. Oder der Software-Anbieter veröffentlicht selbst eine Meldung über eine neu entdeckte Schwachstelle, bevor das Unternehmen überhaupt einen Patch dafür entwickelt hat – wie es Microsoft erst kürzlich bei der Internet Explorer Remote Execution Schwachstelle praktiziert hat.
Nicht jeder ist ein Unterstützer dieser vollständigen Offenlegungspolitik. Auch wenn die Schwachstellen (meist in den wenigsten Fällen) „in the wild“ bereits ausgenutzt werden, so hörte ich (die Autorin des Weblogs) einen Moderator seine persönliche Meinung sagen, dass es eigentlich unverantwortlich ist diese Meldung zu einer Hauptschlagzeile zu machen, wenn der betroffene Software-Anbieter noch keinen Patch für die Schwachstelle entwickelt hat. So eine öffentliche Bekanntmachung einer Schwachstelle klingt eher wie die Einladung an alle Cyberkriminellen: „Nutzt die Schwachstelle solange aus wie ihr könnt!“. Dies wirft eine interessante Frage für Wissenschaftler und Software-Hersteller auf: Bringt eine vorzeitige Veröffentlichung die Nutzer nicht eigentlich mehr in Gefahr – oder ist die nicht sofortige Veröffentlichung eine Unterlassung, die eine noch größere Bedrohung schafft?“
Die Befürworter der absoluten Offenlegung argumentieren, dass ohne die Offenlegung die Software-Anbieter nicht richtig (oder nicht so schnell) motiviert sind, möglichst sofort etwas gegen die Schwachstelle zu unternehmen, als wenn sie durch die Offenlegung bedroht sind. Viele Forscher haben eine Richtlinie, die besagt, dass nach der internen Kommunikation über eine Schwachstelle in der Forschergemeinde der betroffene Anbieter erst eine Chance erhält, die Schwachstelle zu schließen, bevor diese der Öffentlichkeit bekannt gegeben wird. So behauptet beispielsweise die CERT (Computer Emergency Readiness Team) Abteilung des Carnegie Mellon´s Software Engineering Institut, dass: „Schwachstellen, die an das CERT/CC berichtet werden, spätestens nach 45 Tagen nach dem ersten Bericht unabhängig von der Verfügbarkeit von Patches oder Workarounds der betroffenen Hersteller veröffentlicht werden. Unter bestimmten Umständen wie einer aktiven Ausbeutung „in the wild“, Bedrohungen in einer besonders schweren (oder trivialen) Art oder anderen Situationen, die zu einer Änderung des etablierten Standards führen, kann eine Veröffentlichung auch früher oder später erfolgen.
Der IT-Sicherheitsexperte Bruce Schneier hat sich vor einigen Jahren auf die Seite der Befürworter der vollständigen Offenlegung geschlagen mit der Aussage: „Geheimhaltung macht uns nicht wirklich sicherer“ und vertrat die Meinung, dass die vollständige Offenlegung der einzige Grund wäre, warum die Anbieter ihre Systeme überhaupt regelmäßig patchen.
Einige Hacker gehen sogar noch viel weiter. Sie lassen die Öffentlichkeit Informationen über eine neue Schwachstelle erfahren, wenn sie eine neue Schwachstelle entdeckt haben. Aber nicht nur das. Sie veröffentlichen nicht nur die Details über die Schwachstelle, sondern auch wie man diese am besten ausnutzen kann. Andere Hacker verkaufen diese Informationen ganz offen. Aber es gibt auch Hacker (Black Hat Hunters), die wenn sie Schwachstellen gefunden haben diese nicht mir der Öffentlichkeit teilen. Diese Schwachstellen werden lieber verkauft oder für eigene Zwecke (finanziell, politisch, persönlich oder sonstige Gründe) ausgenutzt.
Ob nun eine dritte Stelle für die Offenlegung einer Schwachstelle verantwortlich sein soll oder nicht ist nur der erste Punkt einer Kontroverse. Von denjenigen, die eine „verantwortungsvolle Offenlegung“ befürworten, ist das richtige Timing das zweite Problem. Sind 45 Tage zu lang damit die betroffenen Hersteller reagieren? Oder brauchen die betroffenen Hersteller mehr Zeit um einen Patch zu erstellen und diesen auch ausreichend zu testen, damit der Patch nicht noch mehr Probleme als die Sicherheitslücke verursacht? Wie zu erwarten sind sich die unabhängigen IT-Sicherheitsforscher und die Software Anbieter bei diesen Fragen äußerst uneins.
Die reine Logik würde sagen, dass es keine „jeden zufriedenstellende“ Antwort auf die Frage gibt, da ein begründbarer Zeitrahmen von der Komplexität des Codes, den möglichen Auswirkungen eines Exploits, ob der Exploit bereits „in the wild“ zu beobachten ist oder dem Umfang des potentiellen Risikos (ganz eindeutig stellt eine Schwachstelle in Windows Betriebssystemen oder in einer Applikation wie Adobe Flash, die auf Millionen von Computern installiert sind, eine deutlich größere Bedrohung dar wie eine Schwachstelle, die in einer obskuren Applikation mit einer sehr geringen installierten Basis zu finden ist) abhängig ist.
Ein weiteres Argument für die zumindest teilweise Offenlegung vor der Verfügbarkeit eines Patches ist, dass es eventuell schadensbegrenzende Maßnahmen und Workarounds gibt, die ein individueller Nutzer und/oder ein Administrator implementieren kann, um das mit der Schwachstelle verbundene Risiko zu minimieren. Dies können drastische Maßnahmen wie das Abschalten der Software bis zum Erscheinen eines Patches sein oder auch nur die Änderung einer Einstellung innerhalb der Software (die vielleicht einen mehr oder weniger limitierenden Einfluss auf die Funktionsweise der Software hat).
Es können aber auch rechtliche Fragen bei der Entscheidung, ob Informationen über Schwachstellen öffentlich bekannt gemacht werden sollen, im Vordergrund stehen. Dies trifft besonders in den Fällen zu, bei denen ein „Proof of Concept“ Code das Ausnutzen dieser Schwachstelle demonstriert. Das Veröffentlichen von ausnutzbaren Schwachstelleninformationen an Personen, die diese Informationen höchstwahrscheinlich verwenden, um das Gesetz zu brechen, könnte von einigen als Beihilfe zum Verbrechen angesehen werden. In einigen Fällen könnten solche Veröffentlichungen als Nachweis für eine Verletzung der Anti-Umgehungs-Vorgaben des DMCA (Digital Millenium Copyright Act) angesehen werden. Der betroffene Software-Anbieter könnte möglichweise den Veröffentlicher (z.B. ein unabhängiger IT-Sicherheitsforscher) auf den Diebstahl von Betriebsgeheimnissen, Verletzung des Patentrechts oder einem Vertragsbruch unter den Bestimmungen der EULA (End User License Agreement) oder eines Non-Disclosure Agreements (NDAs) verklagen. Die Forscher könnten aber auch die betroffenen Software-Anbieter erpressen und Geld oder andere Werte verlangen im Austausch dafür, dass die Schwachstelle nicht publiziert wird.
Andererseits könnte man das Recht auf die Informationen über Sicherheitslücken auch unter den ersten Verfassungszusatz zur Meinungsfreiheit stellen. Gut – dieser Schutz von Veröffentlichungen betrifft wahrscheinlich kaum die Veröffentlichung von aktuellen Exploit Code. Es ist hierbei sehr wichtig zu bedenken, dass wir mittlerweile auf einer globalen Ebene leben und arbeiten – und in vielen Ländern nicht der gleiche Schutz der Redefreiheit herrscht wie bspw. in Europa oder in den USA.
Wie sie gut sehen konnten, ist die Frage, ob die Offenlegung von Schwachstellen eine gute oder eine schlechte Sache ist, nicht so einfach zu beantworten. Wie bei vielen Dingen in der IT ist die ehrlichste Antwort auf diese Frage: „Es kommt darauf an….“
Quelle: GFI TalkTechToMe Weblog – Gastautorin: Debra Littlejohn Shinder
Über GFI Software:
GFI Software (www.gfisoftware.de) entwickelt hochwertige IT-Lösungen für kleine und mittlere Unternehmen mit bis zu 1000 Anwendern. GFI bietet zwei wichtige Lösungsplattformen: GFI MAX ermöglicht Managed Service Providers (MSPs) die Bereitstellung von Dienstleistungen an ihre Kunden, und GFI Cloud hilft Unternehmen mit eigenen internen IT-Teams beim Management und bei der Betreuung ihres Netzwerks über die Cloud. Mit mittlerweile über 200.000 Unternehmenskunden umfasst die GFI Produktpalette zudem Collaboration- und Anti-Spam-Lösungen, Netzwerksicherheit, Patch-Management, Faxkommunikation, E-Mail-Archivierung und Web Monitoring. GFI vertreibt seine Produkte indirekt über ein großes weltweites Partner-Netzwerk. Das Unternehmen hat mehrere Preise für seine Technologie gewonnen und ist langjähriger Microsoft Gold ISV Partner.