Vor drei Wochen wurde ein schwerwiegendes Sicherheitsproblem in OS X 10.10.4 entdeckt. Das ist an sich nicht besonders interessant.
Sicherheitslücken in beliebten Softwarepaketen werden ständig entdeckt, und OS X ist keine Ausnahme. Die Open Source Vulnerability Database (OSVDB) zeigt mindestens 1100 Sicherheitslücken, die mit "OS X" gekennzeichnet sind. Was aber interessant ist, ist die Art und Weise, in der diese besondere Schwachstelle offenbart wurde.
Anstatt Apple zu sagen und ihnen Zeit zu geben, das Problem zu beheben, entschied sich der Forscher, seinen Exploit im Internet zu veröffentlichen, damit jeder ihn sehen kann.
Das Endergebnis war ein Wettrüsten zwischen Apple und Black-Hat-Hackern. Apple musste einen Patch veröffentlichen, bevor die Schwachstelle in Angriff genommen wurde, und die Hacker mussten einen Exploit erstellen, bevor die gefährdeten Systeme gepatcht wurden.
Sie könnten denken, dass eine bestimmte Methode der Offenlegung unverantwortlich ist. Man könnte es sogar unethisch oder rücksichtslos nennen. Aber es ist komplizierter als das. Willkommen in der seltsamen, verwirrenden Welt der Offenlegung von Sicherheitslücken.
Full vs Verantwortliche Offenlegung
Es gibt zwei beliebte Möglichkeiten, Schwachstellen für Softwareanbieter aufzudecken.
Die erste heißt vollständige Offenlegung . Ähnlich wie im vorherigen Beispiel veröffentlichen die Forscher ihre Sicherheitsanfälligkeit sofort in der freien Wildbahn, sodass die Anbieter keine Möglichkeit haben, einen Fix zu veröffentlichen.
Die zweite wird verantwortliche Offenlegung oder gestaffelte Offenlegung genannt. Hier kontaktiert der Forscher den Anbieter, bevor die Sicherheitsanfälligkeit bekannt gegeben wird.
Beide Parteien vereinbaren dann einen Zeitrahmen, in dem der Forscher verspricht, die Sicherheitslücke nicht zu veröffentlichen, um dem Anbieter die Möglichkeit zu geben, einen Fix zu erstellen und freizugeben. Dieser Zeitraum kann je nach Schweregrad und Komplexität der Sicherheitsanfälligkeit zwischen 30 Tagen und einem Jahr liegen. Einige Sicherheitslücken können nicht einfach behoben werden und erfordern, dass ganze Softwaresysteme von Grund auf neu erstellt werden.
Sobald beide Parteien mit dem erstellten Fix zufrieden sind, wird die Sicherheitslücke offen gelegt und eine CVE-Nummer erhalten. Sie identifizieren jede Schwachstelle eindeutig und die Schwachstelle wird online in der OSVDB archiviert.
Was aber passiert, wenn die Wartezeit abläuft? Nun, eins von zwei Dingen. Der Verkäufer wird dann eine Verlängerung mit dem Forscher aushandeln. Aber wenn der Forscher nicht damit zufrieden ist, wie der Verkäufer geantwortet oder sich verhalten hat, oder wenn er der Meinung ist, dass die Anfrage nach einer Verlängerung unangemessen ist, könnte er es einfach online veröffentlichen, ohne dass eine Lösung bereit ist.
Im Sicherheitsbereich gibt es hitzige Diskussionen darüber, welche Methode der Offenlegung am besten ist. Einige denken, dass die einzige ethische und genaue Methode die vollständige Offenlegung ist. Einige denken, dass es am besten ist, Anbietern die Möglichkeit zu geben, ein Problem zu beheben, bevor sie in die Freiheit entlassen werden.
Wie sich herausstellt, gibt es zwingende Argumente für beide Seiten.
Die Argumente zugunsten der verantwortlichen Offenlegung
Sehen wir uns ein Beispiel an, in dem es am besten ist, verantwortungsbewusste Offenlegung zu verwenden.
Wenn wir über kritische Infrastruktur im Kontext des Internets sprechen, ist es schwer zu vermeiden, über das DNS-Protokoll zu sprechen. Wie man Ihre DNS-Server ändert und Internet-Sicherheit verbessert Wie Sie Ihre DNS-Server ändern und Internet-Sicherheit verbessern Stellen Sie sich vor - Sie wecken ein schönes Morgen, gieße dir eine Tasse Kaffee ein und setze dich dann an deinen Computer, um mit deiner Arbeit für den Tag zu beginnen. Bevor Sie tatsächlich ... Lesen Sie mehr. Dies ermöglicht uns, lesbare Internetadressen (wie makeuseof.com) in IP-Adressen zu übersetzen.
Das DNS-System ist unglaublich kompliziert und nicht nur auf technischer Ebene. In dieses System wird viel Vertrauen gesetzt. Wir vertrauen darauf, dass wir bei der Eingabe einer Webadresse an den richtigen Ort geschickt werden. Es wird einfach viel Wert auf die Integrität dieses Systems gelegt.
Wenn jemand in der Lage ist, eine DNS-Anfrage zu stören oder zu kompromittieren, besteht eine Menge Schadenspotenzial. Sie könnten beispielsweise Personen auf betrügerische Online-Banking-Seiten schicken und ihnen so ermöglichen, ihre Online-Banking-Daten zu erhalten. 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 untergraben. Gruseliges Zeug.
Dan Kaminsky ist ein angesehener Sicherheitsforscher mit einer langen Zusammenfassung von Schwachstellen in bekannter Software. Aber er ist am bekanntesten für die Entdeckung der vielleicht schwersten Schwachstelle im DNS-System, die jemals gefunden wurde. Dies hätte es jemandem ermöglicht, leicht einen Cache-Poisoning- (oder DNS-Spoofing-) Angriff auf einen DNS-Nameserver durchzuführen. Die technischen Details dieser Sicherheitslücke wurden auf der Def Con-Konferenz 2008 erläutert.
Kaminsky, der sich der Folgen der Veröffentlichung eines so schwerwiegenden Fehlers sehr bewusst war, entschloss sich, dies den Anbietern der DNS-Software, die von diesem Fehler betroffen sind, zu offenbaren.
Es gab eine Reihe von wichtigen DNS-Produkten, darunter solche von Alcatel-Lucent, BlueCoat Technologies, Apple und Cisco. Das Problem betraf auch eine Reihe von DNS-Implementierungen, die mit einigen populären Linux / BSD-Distributionen geliefert wurden, einschließlich denen für Debian, Arch, Gentoo und FreeBSD.
Kaminsky gab ihnen 150 Tage, um eine Lösung zu finden, und arbeitete mit ihnen im Geheimen, um ihnen zu helfen, die Verletzlichkeit zu verstehen. Er wusste, dass dieses Thema so schwerwiegend war und die potenziellen Schäden so groß waren, dass es unglaublich leichtsinnig gewesen wäre, es öffentlich zu veröffentlichen, ohne den Händlern die Möglichkeit zu geben, einen Patch herauszugeben.
Die Sicherheitslücke wurde übrigens von der Sicherheitsfirma Matsano in einem Blogpost zufällig durchgesickert. Der Artikel wurde heruntergenommen, aber es wurde gespiegelt, und einen Tag nach der Veröffentlichung wurde ein Exploit Das ist, wie sie dich hacken: Die düstere Welt der Exploit-Kits Das ist, wie sie dich hacken: Die düstere Welt der Exploit-Kits Betrüger können Software-Suites verwenden Sicherheitslücken 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-Vulnerabilität fasst letztlich den Kern des Arguments zugunsten einer verantwortungsvollen, gestaffelten Offenlegung zusammen. Einige Schwachstellen - wie Zero-Day-Schwachstellen Was ist eine Zero-Day-Schwachstelle? [MakeUseOf Explains] Was ist eine Zero-Day-Schwachstelle? [MakeUseOf Explains] Read More - sind so wichtig, dass die öffentliche Veröffentlichung sie erheblichen Schaden verursachen würde.
Aber es gibt auch ein zwingendes Argument dafür, nicht im Voraus zu warnen.
Der Fall für die vollständige Offenlegung
Indem Sie eine Sicherheitslücke in das Offene austragen, schalten Sie eine Pandora-Box frei, in der unappetitliche Personen schnell und einfach Exploits erstellen und anfällige Systeme kompromittieren können. Also, warum sollte sich jemand dafür entscheiden?
Es gibt ein paar Gründe. Erstens reagieren die Anbieter oft sehr langsam auf Sicherheitsbenachrichtigungen. Indem sie ihre Hand effektiv zwingen, indem sie eine Schwachstelle in die Wildnis entlassen, sind sie motivierter, schnell zu reagieren. Noch schlimmer, einige neigen dazu, nicht zu veröffentlichen, warum Unternehmen Keep Breaches ein Geheimnis ist, kann eine gute Sache sein, warum Unternehmen Breaches ein Geheimnis halten, könnte eine gute Sache sein Mit so vielen Informationen online, 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 ausgeliefert haben. Die vollständige Offenlegung zwingt sie, ehrlich zu ihren Kunden zu sein.
Anscheinend kümmert sich @PepsiCo nicht um eine Schwachstelle auf ihrer Seite, und akzeptiert keine unaufgeforderte Hilfe. Hat schon eine zweite Mannschaft. Ich werde die volle Offenlegung machen
- White Packet (@WhitePacket) 4. September 2015
Aber es ermöglicht den Verbrauchern auch, eine informierte Entscheidung zu treffen, ob sie eine bestimmte, anfällige Software weiterhin verwenden wollen. Ich könnte mir vorstellen, dass die Mehrheit nicht würde.
Was wollen Händler?
Verkäufer mögen wirklich keine vollständige Offenlegung.
Schließlich ist es unglaublich schlecht für sie und ihre Kunden sind in Gefahr. Sie haben versucht, Menschen dazu anzuregen, Schwachstellen verantwortungsvoll durch Bug-Bounty-Programme zu offenbaren. Diese waren bemerkenswert erfolgreich: allein im Jahr 2014 zahlte Google 1, 3 Millionen Dollar.
Es lohnt sich, darauf hinzuweisen, dass einige Unternehmen - wie Oracle Oracle wollen Sie aufhören zu senden sie Bugs - hier ist, warum das verrückt ist Oracle möchte Sie aufhören zu senden sie Bugs - hier ist, warum das verrückt ist Oracle ist in heißem Wasser über einen fehlgeleiteten Blog-Post von Sicherheitschef, Mary Davidson. Diese Demonstration, wie die Sicherheitsphilosophie von Oracle vom Mainstream abweicht, wurde in der Sicherheitsbranche nicht gut aufgenommen. Lesen Sie mehr - entmutigen Sie die Leute, Sicherheitsuntersuchungen an ihrer Software durchzuführen.
Aber es wird immer noch Leute geben, die darauf bestehen, die volle Offenlegung zu benutzen, entweder aus philosophischen Gründen oder zu ihrer eigenen Belustigung. Kein Bug-Bounty-Programm, egal wie großzügig, kann dem entgegenwirken.