Vollständige oder verantwortliche Offenlegung Offenlegung von Sicherheitslücken

Vor drei Wochen wurde ein schwerwiegendes Sicherheitsproblem in OS X 10.10.4 entdeckt. Das ist an sich nicht besonders interessant.

Sicherheitslücken in gängigen Softwarepaketen werden entdeckt die ganze Zeit, und OS X ist keine Ausnahme. Die Open Source Vulnerability Database (OSVDB) weist mindestens 1100 Sicherheitslücken auf, die als gekennzeichnet wurden “OS X”. Aber was ist Interessant ist die Art und Weise, in der diese besondere Schwachstelle aufgedeckt wurde.

Anstatt es Apple mitzuteilen und ihnen Zeit zu geben, um das Problem zu beheben, entschied sich der Forscher, seinen Exploit im Internet zu veröffentlichen, damit alle ihn sehen können.

Das Endergebnis war ein Wettrüsten zwischen Apple und Black-Hat-Hackern. Apple musste einen Patch veröffentlichen, bevor die Sicherheitslücke bewaffnet wurde. Die Hacker mussten einen Exploit erstellen, bevor die gefährdeten Systeme gepatcht werden.

Sie könnten denken, dass eine bestimmte Offenlegungsmethode unverantwortlich ist. Man könnte es sogar als unmoralisch oder rücksichtslos bezeichnen. Aber es ist komplizierter. Willkommen in der fremden, verwirrenden Welt der Offenlegung von Schwachstellen.

Vollständige vs. verantwortliche Offenlegung

Es gibt zwei gängige Möglichkeiten, Schwachstellen für Softwareanbieter offenzulegen.

Der erste heißt vollständige Offenlegung. Ähnlich wie im vorherigen Beispiel veröffentlichen die Forscher ihre Verwundbarkeit sofort in der freien Natur, sodass die Anbieter keinerlei Gelegenheit haben, eine Lösung zu veröffentlichen.

Der zweite wird gerufen verantwortliche Offenlegung, oder gestaffelte Offenlegung. Hier kontaktiert der Forscher den Anbieter, bevor die Sicherheitsanfälligkeit freigegeben wird.

Beide Parteien vereinbaren dann einen Zeitrahmen, in dem der Forscher verspricht, die Sicherheitsanfälligkeit nicht zu veröffentlichen, um dem Anbieter die Möglichkeit zu geben, ein Update zu erstellen und zu veröffentlichen. Diese Zeitspanne kann je nach Schweregrad und Komplexität der Sicherheitsanfälligkeit zwischen 30 Tagen und einem Jahr liegen. Einige Sicherheitslücken lassen sich nicht einfach beheben und es ist erforderlich, dass vollständige Softwaresysteme von Grund auf neu erstellt werden.

Sobald beide Parteien mit dem erstellten Fix zufrieden sind, wird die Sicherheitslücke bekannt gegeben und mit einer CVE-Nummer versehen. Diese identifizieren eindeutig jede Schwachstelle, und die Schwachstelle wird online in der OSVDB archiviert.

Was passiert aber, wenn die Wartezeit abläuft? Nun, eines von zwei Dingen. Der Verkäufer verhandelt dann mit dem Forscher eine Verlängerung. Wenn der Forscher jedoch unzufrieden ist mit der Reaktion oder dem Verhalten des Anbieters oder wenn er der Meinung ist, dass die Anforderung einer Erweiterung nicht zumutbar ist, kann er sie einfach online veröffentlichen, ohne dass ein Fix verfügbar ist.

Im Sicherheitsbereich gibt es heftige Debatten darüber, welche Offenlegungsmethode am besten ist. Einige meinen, dass die einzige ethische und genaue Methode die vollständige Offenlegung ist. Einige sind der Meinung, dass es am besten ist, Anbietern die Möglichkeit zu geben, ein Problem zu beheben, bevor sie in die Wildnis entlassen werden.

Wie sich herausstellt, gibt es für beide Seiten einige überzeugende Argumente.

Die Argumente für eine verantwortungsbewusste Offenlegung

Schauen wir uns ein Beispiel an, wo es am besten war, verantwortungsbewusste Offenlegung zu verwenden.

Wenn wir über kritische Infrastrukturen im Internet sprechen, ist es schwer zu vermeiden, über das DNS-Protokoll zu sprechen. So ändern Sie Ihre DNS-Server und verbessern Sie die Internetsicherheit. Ändern Sie Ihre DNS-Server und verbessern Sie die Internetsicherheit. Stellen Sie sich vor, Sie wachen auf Morgen gießen Sie sich eine Tasse Kaffee und setzen Sie sich dann an Ihren Computer, um mit Ihrer Arbeit für den Tag zu beginnen. Bevor Sie tatsächlich… Lesen Sie mehr. Auf diese Weise können von Menschen lesbare Webadressen (wie makeuseof.com) in IP-Adressen übersetzt werden.

Das DNS-System ist unglaublich kompliziert und nicht nur auf technischer Ebene. In dieses System wird viel Vertrauen gesetzt. Wir vertrauen darauf, dass wir, wenn wir eine Webadresse eingeben, an den richtigen Ort gesendet werden. Es hängt einfach viel von der Integrität dieses Systems ab.

Wenn jemand in der Lage war, eine DNS-Anfrage zu stören oder zu beeinträchtigen, besteht ein großes Potenzial für Schäden. Zum Beispiel könnten sie Personen auf betrügerische Online-Banking-Seiten schicken, wodurch sie ihre Online-Banking-Details erhalten können. Sie konnten ihren E-Mail- und Online-Verkehr durch einen Man-in-the-Middle-Angriff abfangen und den Inhalt lesen. Sie könnten die Sicherheit des Internets als Ganzes grundlegend beeinträchtigen. Gruseliges Zeug.

Dan Kaminsky ist ein angesehener Sicherheitsforscher und kann schon seit langem nach Schwachstellen in bekannter Software suchen. Er ist jedoch vor allem für die Entdeckung der vielleicht schwerwiegendsten Schwachstelle im DNS-System im Jahr 2008 bekannt. Dies hätte es jemandem ermöglicht, auf einfache Weise einen Cache-Poisoning- (oder DNS-Spoofing-) Angriff auf einen DNS-Namenserver durchzuführen. Die technischen Details dieser Sicherheitsanfälligkeit wurden auf der Def Con-Konferenz 2008 erläutert.

Kaminsky, der die Folgen der Veröffentlichung eines solchen schwerwiegenden Fehlers genau bewußt war, entschied sich, ihn den Anbietern der von diesem Fehler betroffenen DNS-Software offenzulegen.

Es gab eine Reihe wichtiger DNS-Produkte, darunter die von Alcatel-Lucent, BlueCoat Technologies, Apple und Cisco. Das Problem betraf auch eine Reihe von DNS-Implementierungen, die im Lieferumfang einiger gängiger Linux / BSD-Distributionen enthalten waren, einschließlich derjenigen für Debian, Arch, Gentoo und FreeBSD.

Kaminsky gab ihnen 150 Tage Zeit, um eine Lösung zu erstellen, und arbeitete im Geheimen mit ihnen zusammen, um ihnen zu helfen, die Sicherheitsanfälligkeit zu verstehen. Er wusste, dass dieses Problem so schwerwiegend war und die potenziellen Schäden so groß waren, dass es unglaublich rücksichtslos gewesen wäre, es öffentlich zu veröffentlichen, ohne den Anbietern die Gelegenheit zu geben, einen Patch herauszugeben.

Übrigens wurde die Sicherheitsanfälligkeit in einem Blog-Post von der Sicherheitsfirma Matsano versehentlich durchgesickert. Der Artikel wurde heruntergenommen, aber es wurde gespiegelt, und ein Tag nach der Veröffentlichung wurde ein Exploit gemacht. Dies ist, wie sie dich hacken: Die düstere Welt der Exploit-Kits Dies ist, wie sie dich hackt: Die Murky-Welt der Exploit-Kits können Software-Suites dazu verwenden Schwachstellen ausnutzen und Malware erstellen. Aber was sind diese Exploit-Kits? Woher kommen sie? Und wie können sie gestoppt werden? Read More wurde erstellt.

Kaminskys DNS-Sicherheitslücke fasst letztendlich den Kernpunkt des Argumentes zugunsten einer verantwortlichen, gestaffelten Offenlegung zusammen. Einige Sicherheitslücken - wie Zero-Day-Sicherheitslücken Was ist eine Sicherheitslücke in Zero Day? [MakeUseOf erklärt] Was ist eine Sicherheitsanfälligkeit durch Zero Day? [MakeUseOf Explains] Read More - sind so bedeutend, dass eine öffentliche Veröffentlichung erheblichen Schaden anrichten würde.

Es gibt aber auch ein überzeugendes Argument dafür, keine Vorwarnung zu geben.

Der Fall für die vollständige Offenlegung

Indem Sie eine Schwachstelle im Freien freigeben, können Sie eine Pandora-Box freischalten, in der unappetitliche Personen schnell und einfach Exploits erzeugen und anfällige Systeme gefährden können. Warum sollte sich jemand dafür entscheiden??

Dafür gibt es einige Gründe. Erstens reagieren Anbieter häufig nur sehr langsam auf Sicherheitsbenachrichtigungen. Indem sie ihre Hand effektiv durch die Freilassung einer Verwundbarkeit erzwingen, sind sie motivierter, schnell zu reagieren. Schlimmer noch: Einige neigen nicht dazu, zu veröffentlichen, warum Unternehmen, die Verstöße gegen ein Geheimnis bewahren, eine gute Sache sein könnten. Warum Unternehmen, die Verstöße gegen ein Geheimnis bewahren, könnten eine gute Sache sein. Angesichts der vielen Online-Informationen machen wir uns alle Sorgen über mögliche Sicherheitsverletzungen. Aber diese Verstöße könnten in den USA geheim gehalten werden, um Sie zu schützen. Es klingt verrückt, also was ist los? Lesen Sie mehr die Tatsache, dass sie anfällige Software versenden. Die vollständige Offenlegung zwingt sie, ihren Kunden gegenüber ehrlich zu sein.

Anscheinend kümmert sich @PepsiCo nicht um einen Vuln auf seiner Website und nimmt keine unerwünschte Hilfe an. Hat schon ein sec Team. Ich werde volle Offenlegung machen

- White Packet (@WhitePacket) 4. September 2015

Verbraucher können jedoch auch eine fundierte Entscheidung treffen, ob sie eine bestimmte, anfällige Software weiterhin verwenden möchten. Ich würde mir die Mehrheit nicht vorstellen.

Was wünschen sich Anbieter??

Anbieter mögen wirklich keine Offenlegung.

Immerhin ist es eine unglaublich schlechte PR für sie, und sie gefährdet ihre Kunden. Sie haben versucht, Anreize dafür zu schaffen, dass Anfälligkeiten durch Bug-Bounty-Programme verantwortungsbewusst offengelegt werden. Diese waren bemerkenswert erfolgreich. Allein 2014 zahlte Google 1,3 Millionen Dollar.

Obwohl es sich lohnt, darauf hinzuweisen, dass einige Unternehmen - wie Oracle Oracle - Sie aufhören sollten, ihnen Fehler zu senden -, ist dies verrückt. Oracle möchte, dass Sie aufhören, sie Fehler zu senden. - Warum verrückt ist Oracle? , Mary Davidson. Diese Demonstration, wie die Sicherheitsphilosophie von Oracle vom Mainstream abweicht, wurde von der Sicherheitsgemeinschaft nicht gut angenommen ... Lesen Sie mehr - entmutigen Sie die Benutzer, Sicherheitsanalysen für ihre Software durchzuführen.

Es wird jedoch immer noch Menschen geben, die darauf bestehen, die vollständige Offenlegung entweder aus philosophischen Gründen oder zur eigenen Belustigung zu nutzen. Kein Bug-Kopfgeld-Programm, egal wie großzügig, kann dem entgegenwirken.

Erfahren Sie mehr über: Computersicherheit, Hacking.