Original-URL des Artikels: https://www.golem.de/news/berichterstattung-ueber-sicherheitsluecken-so-sicher-nicht-1908-142922.html    Veröffentlicht: 02.08.2019 09:30    Kurz-URL: https://glm.io/142922

Berichterstattung über Sicherheitslücken

So sicher nicht

Warnungen vor extrem gefährlichen Sicherheitslücken erreichen uns fast täglich. Doch häufig sind diese halb so wild oder existieren schlicht gar nicht. Wir erklären, wie wir damit umgehen.

Ein Wochenmarkt, auf dem Marktschreier lauthals ihre Ware den Kunden aufschwatzen wollen: An dieses Bild erinnert uns häufig das Verhalten von PR-Agenturen, Sicherheitsfirmen, Behörden und Forschern, wenn es um Sicherheitslücken geht. Sie alle wollen - nach Maßgabe der Aufmerksamkeitsökonomie - ihre Warnungen unter die Leute bringen.

Insbesondere Sicherheitsfirmen kontaktieren uns fast täglich mit Pressemeldungen und Berichten über angeblich extrem gefährliche Sicherheitslücken, welche die IT-Welt bedrohten. Bei näherem Hinsehen zeigt sich oft, dass die Berichte aufgebauscht und wichtige Details weggelassen wurden.

Doch nicht jeder Journalist hat die Expertise, die Fehlinformationen zu erkennen. Deshalb sichert diese Praxis oft eine Berichterstattung in den General-Interest-Medien und raubt Technikjournalisten wie uns eine Menge Zeit.

Gefährlich, gefährlich

Ein aktuelles Beispiel: Eine Schadsoftware nutzt eine gefährliche Sicherheitslücke in Android aus, mit der sich Apps klonen lassen, eine Art böser App-Zwilling mit Schadcode entsteht. Was die Pressemitteilung und der ausführliche Blogeintrag unerwähnt lassen: Die zugrunde liegende Sicherheitslücke wurde bereits im Jahr 2017 entdeckt und geschlossen. Ziel der Schadsoftware ist zudem der asiatische Raum, allen voran Indien.

Das ist eine häufige Vorgehensweise: In der Pressemitteilung werden Sicherheitslücken als gefährlich bezeichnet, nur ein Detail in der als Basis verwendeten Studie verrät, dass sie eigentlich gar nicht so wild sind.

Der angeblich unsichere VLC-Player

Manchmal werden in Mitteilungen über Sicherheitslücken die Sachverhalte so verzerrt, dass es fast schon unlauter ist. So informierte die Cisco-Tochter Talos im Oktober 2018 über eine Sicherheitslücke im Streamingserver LIVE555. Auf der Webseite hieß es dazu: "TALOS-2018-0684 beschreibt die Schwachstelle CVE-2018-4013. Die LIVE555 Medienbibliotheken sind leichtgewichtige Multimedia-Streaming-Bibliotheken für RTSP/RTCP/RTCP/RTSP/SIP, mit Codeunterstützung für Server und Clients. Sie werden von gängigen Medienplayern wie VLC und MPlayer sowie einer Vielzahl von Embedded-Geräten (hauptsächlich Kameras) genutzt." Tatsächlich betrifft die Sicherheitslücke, über die sich Code ausführen lässt, nur den LIVE555-Server, im VLC-Player wird jedoch nur der Client eingesetzt.

Der Bezug auf den VLC-Player scheint beabsichtigt zu sein. Mit der Erwähnung einer Software, die fast jeder Nutzer kennt, und die millionenfach verwendet wird, kann die Sicherheitsfirma deutlich mehr Aufmerksamkeit erregen. Und wie erhofft berichteten etliche Tech-Medien über eine gefährliche Sicherheitslücke im VLC-Player. In den Kommentaren darunter fragten Nutzer offenbar verzweifelt, wann mit einem Update zu rechnen sei.

Ähnlich verlief es bei einer angeblichen Sicherheitslücke im VLC-Player, die vergangene Woche bekannt wurde. Die US-Behörde Nist und das Cert-Bund warnten vor ihr - dass Behörden bei der Bewertung von Sicherheitslücken und der Informationsarbeit nicht immer positiv abschneiden, haben wir bereits in einer Analyse beleuchtet. Viele Medien weltweit nahmen die Warnungen auf. Doch die vermeintliche Sicherheitslücke, vor der das Cert-Bund warnte, existierte in dieser Form schlicht nicht.

Vielmehr handelte es sich um eine Lücke in einer Bibliothek, die von vielen Media-Playern eingesetzt wird. Diese wurde zudem bereits vor mehr als einem Jahr geschlossen, auch im VLC-Player, und hätte sich zudem nicht wirklich ausnutzen lassen.

Wie können wir Journalisten falsche Berichte über Sicherheitslücken verhindern?



Einen sicheren Umgang finden

Als Journalisten sind wir gefragt, Informationen nicht nur aufzubereiten, sondern auch zu hinterfragen und zu überprüfen. Im besten Fall können wir die Sicherheitsprobleme selbst nachstellen und bestätigen, beispielsweise mit virtuellen Maschinen. Doch häufig liefern Sicherheitsforscher und Sicherheitsfirmen nur vage Beschreibungen der entdeckten Sicherheitslücken und keine fertigen Exploits, die wir testen könnten.

Das geschieht meist aus zwei Gründen: Zum einen wollen Forscher und Firmen die Betroffenen schützen, welche die entsprechenden Updates noch nicht erhalten oder eingespielt haben. Zum anderen ist das Schreiben eines Exploits nicht nur für die Autoren von Schadsoftware aufwendig, sondern auch für die Entdecker der Sicherheitslücke. Entsprechend beschreiben sie oft nur die Sicherheitslücke - ohne Exploit.

Das Nachstellen kostet zudem häufig nicht nur viel Zeit, sondern stößt auch schnell an Grenzen: Sicherheitslücken in Industriesystemen, sehr spezieller und teurer Software oder wenig genutzten Protokollen können wir schlecht verifizieren. Wir haben weder Beatmungsgeräte noch Scada-Systeme oder Flugzeuge in der Redaktion.

In vielen Fällen bleiben nur kurze Beschreibungen oder Demonstrationsvideos, die erfolgreiche Angriffe zeigen, sowie ein Rückgriff auf die eigene Erfahrung und das Vertrauen in die Primärquellen. Auf dieser Basis versuchen wir, die Sicherheitslücke nachzuvollziehen und deren potentielle Gefährlichkeit abzuschätzen.

Schwierig wird es mit der Nachvollziehbarkeit auch, wenn die Informationen über Sicherheitslücken auf umfangreichen Recherchen anderer Redaktionen beruhen. Ein Beispiel war eine Recherche von Bloomberg zu chinesischen Spionagechips, die über einen Angriff auf die Lieferkette in Servern von Supermicro eingebracht worden sein sollen. Bloomberg beruft sich auf 17 Quellen aus dem Regierungs- und Firmenumfeld, die unabhängig voneinander die Existenz der Mikrochips in den Servern bestätigt haben sollen. Die betroffenen Firmen dementierten die Berichterstattung. Unabhängig überprüfen konnten wir das nicht. Wir haben daher den Bericht, die Diskussion und die Fakten für unsere Leser aufbereitet.

Doch wie entscheiden wir, über welche Sicherheitslücken auf Golem.de berichtet wird, und über welche nicht?

Wann wir über Sicherheitslücken berichten

Halten wir eine Sicherheitslücke für nachvollziehbar, wägen wir mehrere Faktoren bei der Frage ab, ob wir über sie berichten: Wie gefährlich ist die Sicherheitslücke? Wie leicht lässt sie sich ausnutzen? Wie wichtig und verbreitet ist die Soft- oder Hardware bei unseren Lesern? Wie interessant und neuartig ist der Ansatz? Wie alt ist die Sicherheitslücke, und gibt es Patches?

Diese Abwägungen sind ein zentraler Bestandteil unserer journalistischen Arbeit und geschehen im Onlinejournalismus, in dem Leser eine schnelle Berichterstattung erwarten, meist unter hohem Zeitdruck. Dabei kommt es häufig vor, dass wir Sicherheitslücken zwar spannend finden, es aber eine deutliche Einschränkung gibt, beispielsweise was die Ausnutzbarkeit angeht. In diesen Fällen betonen wir diese Einschränkungen in unserer Berichterstattung deutlich.

Diese Abwägung führt jedoch auch häufig dazu, dass wir über eine Sicherheitslücke nicht berichten. Wir wollen unseren Lesern schlicht nicht laufend Berichte über uninteressante, aufgebauschte oder nicht existente Sicherheitslücken zumuten.

So haben wir uns bereits beim Aufkommen der Berichterstattung über die VLC-Sicherheitslücke gegen einen Artikel entschieden, weil wir die Beschreibung einer Remote-Code-Execution durch eine Datei und einen Buffer-Overflow-Read nicht nachvollziehen konnten. Auch den beschriebenen Absturz konnten wir nicht nachstellen.

Erst als die Berichterstattung auch die Massenmedien erreichte, und das Videolan-Projekt sich öffentlich über die falschen Darstellungen beschwerte, haben wir uns erneut mit der angeblichen Lücke auseinandergesetzt und dargelegt, dass es sich um keine handelte - und die Kritik der Entwickler thematisiert.

Fehler können passieren

Dennoch können - bei aller Vorsicht - auch Fehler passieren. Wichtig ist es dann, transparent darüber zu berichten, was im Fall der VLC-Lücke leider nicht überall passierte. Einige Medien ließen ihre Artikel unkorrigiert oder löschten sie kommentarlos. Die Leser erfuhren also nicht, dass der Bericht fehlerhaft war.

Uns ist wichtig, dass Korrekturen unsere Leser auch erreichen - auch wenn wir am liebsten gar nicht erst so einen Fehler machen würden, wie er uns etwa im Oktober 2018 unterlief. Damals berichteten wir irrtümlich, dass über eine Sicherheitslücke in Windows Administratorenrechte erlangt werden könnten. Diese konnten jedoch nur weitergegeben werden, wenn man selbst schon Admin-Rechte hatte.

Bei all den Fallstricken, Problemen und Unwägbarkeiten versuchen wir, bestmöglich zu arbeiten und Transparenz für unsere Leser zu schaffen. Dieser Text soll einen Beitrag dazu leisten. Einfacher wird unsere Arbeit dadurch nicht.  (mtr)


Verwandte Artikel:
IT-Security: Hoodie-Klischeebilder sollen durch Wettbewerb verschwinden   
(01.08.2019, https://glm.io/142937 )
Konbini: 7-Eleven beendet Zahlungssystem 7pay komplett   
(01.08.2019, https://glm.io/142923 )
Scroll: Mozilla unterstützt Flatrate-News-App   
(26.02.2019, https://glm.io/139650 )
Social Engineering: Die unterschätzte Gefahr   
(01.08.2019, https://glm.io/142812 )
Videoüberwachung: Cisco einigt sich mit US-Regierung wegen unsicherer Software   
(01.08.2019, https://glm.io/142919 )

© 1997–2019 Golem.de, https://www.golem.de/