Suche
Close this search box.

Kommunikation bei einem IT-Sicherheitsvorfall, was kann da schon schiefgehen?

Dass bei der Kommunikation von IT-Sicherheits-Vorfällen einiges schiefgehen kann, ist wohl eine Binsenwahrheit. Zwei konkrete Beispiele der letzten Wochen haben das wieder einmal deutlich vor Augen geführt.

Eines vorneweg: Der Fokus liegt im folgenden auf der Art der Kommunikation, nicht auf den Vorfällen (da liegen definitiv Welten zwischen einem Informationen preisgebenden und angreifbaren Passwort-Manager und einigen schlussendlich eher theoretischen Lücken in einem Messenger).

LastPass

LastPass ist ein weitverbreiteter Password-Manager für alle gängigen Betriebssysteme mit dem sich Passwörter zwischen verschiedenen Rechnern/Geräten synchronisieren lassen damit sie auf allen Geräten zur Verfügung stehen (was es einem erlaubt, komplexe Passwörter für Online-Dienste zu verwenden welche schwer zu knacken sind). Da diese Synchronisierung über das Internet erfolgt, ist die Sicherheit der Passwort-Daten zentral für die Vertrauenswürdigkeit des Produkts, der Zugriff auf die Daten wird durch ein vom Kunden gesetztes Master-Passwort geschützt.

Technischer Einschub: Bei LastPass wird (wie bei anderen gängigen Passwort-Managern auch) nicht das Master-Passwort nicht direkt zum Verschlüsseln der Daten verwendet da es oft zu einfach erratbar/angreifbar ist. Stattdessen wird es mit einer kryptografischen Funktion namens Password-Based Key Derivation Function quasi mathematisch zufälliger gemacht um so die Sicherheit zu erhöhen. Allerdings ist PBKDF relativ leicht in Hardware zu realisieren, daher ist momentan die Verwendung von >200’000 Iterationen/Durchläufen des Algorithmus Standard (zum Vergleich: in 2005 wurden 4000 Iterationen noch als ausreichend betrachtet).

LastPass hatte in den letzten Jahren wiederholt Sicherheitsprobleme, so wurden unter anderem 2017 schwerwiegende Schwächen bekannt, erfolgte 2016 ein Phishing-Attacke und gingen 2015 bereits Daten «verloren».

Im zweiten Halbjahr 2022 kam eine weiteres Problem hinzu, welches das Unternehmen in einem immer länger werdenden Blogpost zum Vorfall Stück für Stück bekannt machte. Ein Problem welches bei jedem Blogpost-Update grösser und grösser wurde…

  • Am 25.8. wurde die Entwendung von Source Code durch unbekannte Hacker bekannt gegeben. Auch wenn versichert wurde, dass keine Kundendaten entwendet worden seien und Kunden keine spezifischen Massnahmen ergreifen müssten, ist schon der Zugriff von Fremden auf proprietären Source Code (in dem anschliessend nach Sicherheitslücken gesucht werden kann) ein ernstes Problem.
  • Drei Wochen später ergänzte LastPass die Meldung um Details zum Zugriff und betonte explizit, dass Kunden-Daten und -Passwörter nicht in Gefahr wären und kein Zugriff darauf erfolgt sei («We can also confirm that there is no evidence that this incident involved any access to customer data or encrypted password vaults. […] your personal data and passwords are safe in our care»).
  • Die Freude währte kurz, denn am 30.11. informierte das Unternehmen darüber, dass es unbekannten Dritten mit Hilfe der im August kopierten Daten möglich gewesen war, auf einen Cloudspeicher mit Kundendaten zuzugreifen. Das Unternehmen versicherte erneut, dass die Kunden-Passwörter verschlüsselt und sicher seien.
  • Am 22.12. schlussendlich musste LastPass eingestehen, dass entgegen der bisherigen Kommunikation nicht nur Daten aus den Passwort-Safes der Kunden abgeflossen seien, sondern dass diese, mit Ausnahme von Attributen wie Login-Daten und verschlüsselten Notizen, unverschlüsselt waren und von den Angreifern lesbar seien (darunter zum Beispiel auch die zu einem Login gehörige URL, womit es dem Angreifer leicht gemacht wird, attraktive Ziele fürs Knacken des Passworts schnell zu erkennen). Verbunden war dieses Eingeständnis mit Hinweisen auf von den Kunden vorzunehmenden Massnahmen und einer Beschreibung wieso LastPass trotz allem sicher sei.

Aus „Uuups, es hat uns zwar jemand den Quellcode geklaut aber alles kein Problem“ wurde so innert vier Monaten „es wurden Passwort-Safes von Kunden entwendet und die darin enthaltenen Daten sind teilweise gar nicht verschlüsselt“. Und auch wenn das jeweilige Master-Passwort der Kunden nicht geknackt wurde, so enthalten die unverschlüsselten Teile des Passwort-Safes oft genügend identifizierende Details um Passwort-Safes zu identifizieren bei denen sich das Knacken dieses Master-Passworts lohnen könnte.

Es dauerte anschliessend nicht lange, bis IT Security-Experten auf diverse Ungereimtheiten in der Kommunikation und den Ereignissen hinwiesen:

  • Die Kommunikation am 22.12. führte dazu, dass die Brisanz im Weihachtstrubel weitgehend unterging (und wohl auch viele Kunden gar nicht realisierten, welche Probleme da auf sie zukommen).
  • Es ist schwer erklärbar, wieso LastPass nicht schon im September erkannt haben soll, dass neben Teilen des Source Codes auch Zugriffsschlüssel für den Cloudspeicher entwendet wurden. «Solche Schlüssel dürfen nicht in einer Entwicklungsumgebung gespeichert werden» mag als Richtlinie zwar gelten, aber im Falle eines unautorisierten Zugriffs sollte man sich da, vor allem als Unternehmen aus dem Sicherheitsbereich, nicht darauf verlassen und eine Prüfung vornehmen. Wenn man nicht sowieso aus reiner Vorsicht vom Schlimmsten ausgeht und alle Zugangsdaten generell erneuert.
  • Auf die Problematik der nicht-verschlüsselten Zusatzdaten wie URLs wurde LastPass schon in der Vergangenheit (2015, 2017, 2018) mehrfach aufmerksam gemacht. Das Unternehmen sah es offenbar nicht als notwendig an, da etwas zu ändern.
  • Die im Blog-Post unter «What Should LastPass Customers Do?» empfohlenen Massnahmen (Masterpassword mindestens 12-stellig, >100’000 Iterationen für die Schlüssel-Generierung (siehe technischer Einschub am Anfang dieses Artikels)) tönen zwar gut, werden in der Praxis von LastPass aber in keinster Weise aktiv eingefordert: Wer seit Jahren ein kürzeres Passwort nutzte, wurde nie dazu gezwungen, ein längeres zu verwenden; viele seit längerem bestehenden Accounts haben bei der Schlüssel-Generierung Iterations-Werte deutlich unter 100’000 definiert. Bei beidem hätte LastPass schon seit längerer Zeit die Sicherheitsstandards selbständig erhöhen können (und bei den Iterationen stellt sich die grundsätzliche Frage, wieso Nutzerinnen überhaupt unsichere Werte definieren können), zieht es im Blogpost mit Formulierungen wie «If you use the default settings above» aber vor, den Kunden die Schuld in die Schuhe zu schieben (da die Default-Settings bei älteren Accounts eben nicht greifen).

Kein Wunder also, dass diverse Blogs von IT-Sicherheitsexperten wie auch verschiedene Medienberichte sehr explizit empfahlen, auf einen anderen Passwort-Manager zu wechseln da LastPass weder als Produkt noch als Unternehmen weiter vertrauenswürdig seien. Die Tatsache, dass der Besitzer von LastPass unterdessen weitere Lecks bekannt gegeben hat, dürfte dies noch unterstreichen.

Threema

Anfangs Oktober 2022 wurde Threema von der Applied Cryptography Group der ETH Zurich über eine Reihe von Schwachstellen im Messenger informiert welche ein Master-Student im Rahmen seiner Masterarbeit entdeckt hatte. Die Forschungsgruppe und das Unternehmen vereinbarten in der Folge eine dreimonatige Stillhaltefrist während der das Unternehmen die Probleme beheben konnte, und eine öffentliche Bekanntmachung («public disclosure») anfangs 2023.

Diese erfolgte dann am 9. Januar auf mehreren Kanälen:

  • Das Unternehmen selbst publizierte unter dem Titel «New Paper on Old Threema Protocol» eine technisch fokussierte Erklärung der Forschungsergebnisse und der ergriffenen Massnahmen. Es betonte dabei insbesondere, dass die gefundenen Schwachstellen unter reellen Bedingungen nicht ausnutzbar gewesen wären und in den neusten Versionen entweder behoben oder durch die mittlerweile erfolgte Einführung eines neuen Protokolls obselet geworden waren.
  • Die Forschungsgruppe publizierte ihre Ergebnisse auf einer eigens aufgesetzten Website mit dem sprechenden Namen breakingthe3ma.app. Auf dieser werden die gefundenen Schwachstellen teilweise recht drastisch beschrieben, auch findet sich ein Link auf ein Paper mit weiterführenden Details.
  • In der NZZ erschien ein längerer Artikel mit dem Titel «Verschlüsselung hinkt Jahre hinterher: Der Schweizer Messenger Threema setzte bis vor kurzem auf veraltete Kryptografie». Und auch wenn der Artikel inhaltlich versucht, verschiedene Stimmen (inklusive dem Anbieter selbst) zu Wort kommen zu lassen, geben sowohl der Titel wie auch einzelne Abschnitte dem Thema einen negativen Spin.

In der Folge passierte, was in solchen Fällen schnell mal passiert: Die schnelle und weite Verbreitung sowohl des NZZ-Artikels wie auch der speziell aufgeschalteten ETH-Webseite via Social Media und einschlägigen Kanälen führten dazu, dass die sachliche (aber vielleicht etwas trockene und defensive) Darstellung des Anbieters kaum Beachtung fand. Auch der den eigenen Blogpost ankündigende Tweet rief mit einer tendenziell passiv-aggressiven Formulierung zumindest auf Twitter primär negative Reaktionen hervor.

Und spätestens nachdem die internationale Tech-Presse mit Titel wie «Threema Under Fire After Downplaying Security Research» und «Messenger billed as better than Signal is riddled with vulnerabilities» berichtete, und selbst Bruce Schneier den Blog-Post von Threema mit «The company is performing the usual denials and deflections» referenzierte, hatte Threema die Kontrolle über die Kommunikation definitiv verloren und fand sich inmitten eines Security-Shitstorms wieder.

Da half dann auch der weit über die offizielle Kommunikation hinausgehende Blog-Post eines Threema-Mitarbeiters nicht mehr, der die Hintergründe einiger der kritisierten Design-Entscheide offenlegte und auch aufzeigte, welche (teilweise unrealistischen) Voraussetzungen hätten erfüllt sein müssen um die identifizierten Schwachstellen effektiv auszunutzen. Auch Threema selbst aktualisierte den bereits publizierten Beitrag und gab ihm einen neuen Titel, die allgemeine Berichterstattung lässt zumindest bezweifeln, dass er breit gelesen wurde.

So geriet der Realitätscheck in der medialen Aufregung genauso vergessen wie die eigentlich wichtige Feststellung, dass Verschlüsselungsalgorithmen und -protokolle zwingend offengelegt und von unabhängigen Stellen geprüft werden sollten um das Vertrauen ins Produkt zu steigern. Und Threema wurde für die Bemühungen zur Behebung der Schwachstellen mit eher schlechten Publicity „belohnt“, selbst der schon seit längerem geplante Rollout des verbesserten Verschlüsselungsprotokolls (welcher ja im Grunde genommen als positive Massnahme hätte beworben werden können) wurde vielenorts als überhastete defensive Handlung interpretiert.

Was könnte man besser machen?

Kurz gesagt, einiges, in beiden Fällen.

Grundsätzlich gibt es in Krisen (unabhängig davon ob das jetzt ein Flugzeugabsturz, ein Produktrückruf oder eben ein Cyber-Vorfall ist) einige zentrale Kommunikationsregeln die man grundsätzlich beachten sollte. Die finden sich in jedem einschlägigen Handbuch (und sind den jeweiligen Kommunikationsverantwortlichen hoffentlich geläufig):

  • Offene und ehrliche Kommunikation: Sagen was passiert ist, ohne Dinge zu beschönigen oder sich als Opfer dunkler Machenschaften darzustellen. Das schafft Vertrauen und beugt Gerüchten vor (die sich zwar nie ganz vermeiden, mit einer offenen Kommunikation aber im Normalfall unter Kontrolle halten lassen).
  • Auswirkungen klar kommunizieren: Wer oder was ist betroffen, wer oder was nicht; verbunden allenfalls mit Handlungsanweisungen an die Betroffenen oder Empfehlungen für alle Nutzer. Auch hier gilt, zu dem zu stehen was man noch nicht weiss, und lieber mal im Interesse des Kunden zu vorsichtig zu sein (zum Beispiel im Stil von «We are still assessing the number of accounts impacted, but we have reset the passwords on all accounts. Clients can regain access by selecting «I forgot my password» the next time they want to log in.»).
  • Weitere Schritte und Updates: Je nach Grösse des Vorfalls ist es mit einer einzelnen Meldung nicht getan. Das Klären von noch offenen Punkten kann ein paar Stunden oder Tage dauern, Analysen zusammen mit Partnern (oder Strafbehörden) können notwendig sein, im schlimmsten Fall sind zum Zeitpunkt der Erstinformationen generell noch wenig Details bekannt. Da ist es dann wichtig, dass den Kunden zumindest klar ist, in welchen Zeitraum mit weiteren Informationen zu rechnen ist (und was sie zwischenzeitlich allenfalls tun oder eben nicht tun sollten).

Etwas ausführlicher hat es Dominic Bertram an der ISSS Conference in Bern vor ein paar Tagen beschrieben. In einem Vortrag (noch nicht online) mit dem Titel «Communicating in the eye of the storm: Dos and Don‘ts for cyber crisis communications» präsentierte er je sechs Punkte die es bei der Kommunikation von Cyber-Vorfällen zu berücksichtigen oder eben zu vermeiden gilt.

  • Kenne Deine Stakeholder und ihre Bedürfnisse: Simpel gesagt ist dies das A&O jeglicher Kommunikation: Wenn ich nicht weiss mit wem ich rede, kann ich auch die Botschaft nicht empfängergerecht aufbereiten. Bezogen auf Sicherheitsvorfälle bedeutet dies unter anderem, dass die Medienmitteilung ans breite Publikum anders geschrieben werden muss als die konkrete Information an die Kunden (welche uU detaillierte Handlungsanweisungen erwarten), und eine allfällige technische Analyse für interessierte Fachleute dann nochmals anders formuliert sein muss. Als zusätzliche Herausforderung muss man davon ausgehen, dass sich die verschiedenen Stakeholder-Gruppen überlappen, Mitteilungen an die verschiedenen Gruppen sollten sich daher mit Vorteil ergänzen (und nicht widersprechen) und auch nicht eine nicht direkt addressierte Gruppe vor den Kopf stossen.
  • Sei Dir Deiner Pflichten bewusst: Je nach Art des Vorfalls bestehen gesetzliche Vorgaben welche einzuhalten sind. Im ab September 2023 geltenden Datenschutzgesetz ist die Information betroffenener Nutzerinnen vorgesehen, unter Umständen besteht eine generelle Meldepflicht und bei international relevanten Applikationen oder Plattformen kommen abhängig vom Standort der betroffenen Nutzer zusätzliche Regeln dazu.
  • Versuche nicht, den Vorfall zu vertuschen oder auszusitzen: Egal ob Du selber auf eine sicherheitsrelevante Schwachstelle stösst, oder Du von Dritten darauf aufmerksam gemacht wirst: Wenn es mal jemand rausgefunden hat, werden es in Zukunft auch andere rausfinden, also ist es eine Frage der Zeit bis es öffentlich wird. Und da kommuniziert man am besten zeitgerecht selbst, einerseits um den eigenen Kunden weiteren Schaden zu ersparen (bzw. ihnen zu ermöglichen, einen solchen einzudämmen), andererseits um die Kontrolle über die Kommunikation und ein allfälliges Framing zu behalten. Das heisst natürlich nicht, dass man bei Sicherheitslücken kein Responsible Disclosure anwenden sollte. Aber das Ziel von Responsible Disclosure ist es, den Entwicklern Zeit zum Schliessen von Lücken zu geben bevor man sie kommuniziert (und so zu vermeiden, dass sie von jedem Möchtegern-Hacker ausgenutzt wird). Es kann nicht die Idee sein, diese Frist quasi ins Unendliche auszudehnen (mit ein Grund, wieso die Offenlegungs-Frist meist nur wenige Wochen oder Monate beträgt).
  • Übernimm Verantwortung, stell Dich nicht als Opfer dar und spiel den Vorfall nicht runter: Fehler passieren, man tut gut daran, dazu zu stehen wenn sie bekannt werden. Eine «wir sind Opfer von bösen Hackern»-Strategie mag vielleicht bei unkritischen Medien teilweise funktionieren, aber sowohl bei Kunden wie auch bei interessierten Fachkreisen löst sie primär Stirnrunzeln und Misstrauen aus. Genau dieselben Fachkreise sind dann durchaus auch in der Lage, eine allzu schönmalerische Beschreibung des Vorfalls und dessen Auswirkungen zu durchschauen, und dies auch selbst entsprechend zu kommunizieren. Insofern ist «Hinstehen und sagen was ist» der beste Weg, um das Vertrauen der Stakeholder nicht zu verlieren und auch nicht die Kontrolle über den Inhalt der Kommunikation zu verlieren.
  • Hole Vertrauen durch die Kommunikation von Korrekturmassnahmen zurück: Zu Fehlern zu stehen ist der wichtige erste Schritt, oft genauso wichtig ist anschliessend die Kommunikation der aus dem Fehler gezogenen Lehren und Massnahmen. Damit kann man deutlich machen, dass man gewillt ist, denselben Fehler nicht nochmals zu machen. Gerade bei Unternehmen im Security-Bereich ist es auch eine naheliegende Möglichkeit, einen zum Beispiel im Leitbild stehenden Satz «bei uns steht Sicherheit an erster Stelle» in der Praxis zu demonstrieren.
  • Kommuniziere aktiv und rechtzeitig, behalte die Kommunikationsoberhand: Das geht weitgehend schon aus den obigen Punkten hervor, gerade die Thematik der Kommunikationsoberhand sollte man definitiv nicht unterschätzen. Wer ein Thema bzw. eine Sicherheitslücke als erstes kommuniziert, hat die Deutungshoheit über die Beschreibung und die wahrgenommene Kritikalität. Sollte die Oberhand nicht beim betroffenen Unternehmen selber liegen, dann ist dieses schnell mal der öffentlichen Wahrnehmung ausgeliefert und schon von Anfang an in der Defensive.

Wenn wir nun mit diesen Punkten in der Hand nochmals die Krisenkommunikation der beiden eingangs erwähnten Beispiele betrachten, dann fällt folgendes auf:

  • Von einer offenen und ehrlichen Kommunikation durch LastPass kann man beim besten Willen nicht sprechen. Die Lücken und (potentiellen) Datenabflüsse wurden schleppend und spät kommuniziert, Schwachstellen schöngeredet (und seit Jahren offene Probleme nicht behoben) und die Verantwortung für die Datensicherheit bei den Kunden auch bei Aspekten in die Schuhe geschoben wo das Unternehmen selber nachbessern könnte. Gerade für einen Internet-basierten Password-Manager (bei dem man sich als Kunde ja darauf verlassen muss, dass der Anbieter alles richtig macht) ist das fatal. Ob diese Strategie (die wohl darauf hofft, dass die meisten Nutzer es nicht merken und/oder Lastpass wegen dem verhältnismässig hohen Aufwand für den Wechsel zu einer anderen Lösung nicht deinstallieren) aufgeht, wird sich zeigen. Die Tatsache, dass diverse Sicherheitsforscher und Blogposts von der weiteren Nutzung von Lastpass abraten, deutet eher darauf hin, dass sie nicht funktionieren wird.
  • Ein gutes Anschauungsbeispiel für den Verlust der Kommunikationsoberhand und die daraus entstehenden Probleme zeigt sich bei Threema. Natürlich kann das Unternehmen nix dafür, dass sowohl die Präsentation der Forschungsergebnisse durch die ETH wie auch der NZZ-Artikel die gefundenen Schwächen in ein allzu krasses Licht rückten. Aber „bad news travel faster“ gilt auch im Medienbusiness und so erreichten die «Threema ist nicht sicher»-Schlagzeilen deutlich mehr Verbreitung als die nüchternen und sich primär an ein technisch affines Fachpublikum wendenden Ausführungen im Statement des Unternehmens selbst. Die Deutungshoheit der (zum Publikationszeitpunkt ja bereits behobenen) Schwachstellen lag daher von Anfang an nicht beim Unternehmen selbst, welches so gezwungen war, aus der Defensive her das Vertrauen der Nutzer ins Produkt mit einem wiederholten Aktualisieren des eigenen Statements und viel Medienarbeit wieder herzustellen.

Auch wenn die Fälle aus technischer Sicht unterschiedlicher nicht sein könnten (Lastpass hatte bereits einen schlechten Security-Track Record, die technischen Lücken in Q3/Q4 2022 schlecht kommuniziert/vertuscht und ist sowohl technisch wie auch organisatorisch nicht mehr vertrauenswürdig; Threema hat die Responsible Disclosure-Frist dazu genutzt, mit dem sich bereits in Entwicklung befindlichen Protokoll-Update die Probleme an der Wurzel zu lösen und ist technisch nach aktuellem Wissen sicher), zeigen beide doch deutlich, dass bei Security-Vorfällen eine gute, aktive Kommunikation zentral ist.

Die Zeiten, in denen Applikationen von Nerds für Nerds entwickelt wurden, der Fokus rein auf der Technik lag und man quasi unter Gleichgesinnten kommunizierte, sind wohl definitiv vorbei. Ohne klare (Krisen-)Kommunikationsstrategie und für die Allgemeinheit verständliche Messages laufen auch IT-Unternehmen Gefahr, im Falle einer realen oder schon nur herbeigeredeten Krise von den Ereignissen überrollt zu werden.

dnip.ch mit Deiner Spende unterstützen

Wir wollen, dass unsere Inhalte frei verfügbar sind, weil wir es wichtig finden, dass möglichst viele Menschen in unserem Land die politischen Dimensionen der Digitalisierung erkennen und verstehen können.

Damit das möglich ist, sind wir auf deine Unterstützung angewiesen. Jeder Beitrag und sei er noch so klein, hilft uns, unsere Aufgabe wahrzunehmen.

11 Antworten

  1. Was ich nicht verstehen kann/will: Warum hat die ETH Gruppe das getan?
    Was hat sie daraus gewonnen? Welches Unternehmen will das nächste Mal mit der Gruppe zusammenarbeiten wenn man danach den Medien zum Frass vorgeworfen wird, obschon man technisch alles richtig macht?
    Was gewinnt man so? Ein gutes Produkt in die Pfanne zu werfen um damit Signal und WhatsApp (shiver) zu helfen? Was hat das mit ‚IT Security‘ zu tun? Ist da persönlicher Beef, der auf dem Rücken der Konsumenten augetrragen wird?

    1. Die ETH-Gruppe hat gar nicht viel gemacht, ausser das Protokoll zu analysieren und die Ergebnisse zu publizeren – Soweit Standard. Da brauchts keinen Auftrag eines Unternehmens. Man kann aber debattieren, ob es wirklich eine eigene Domain dafür braucht und wie man dort formuliert. Threema als betroffenes Unternehmen ist aber nicht in der Position, diese Debatte zum Zeitpunkt der Veröffentlichung anzustossen.

      Den Shitstorm hat sich Threema mit der eigenen Kommunikation selbst eingebrockt. Erst dadurch wurde das Thema überhaupt weit in die Security-Community getragen. Und die reagiert auf dieses Verhalten halt allergisch.

      1. Um ehrlich zu sein, hat die Kommunikation von Threema meiner Meinung nach nicht viel dazu beigetragen – diese kam zu spät. Zu dem Zeitpunkt kursierte in der Security-Community bereits die Darstellung der Forschenden, Threema hätte gravierende Fehler bei der Umsetzung der Verschlüsselung gemacht.

        Threema hat dieses Bild in ihrem Statement geradegerückt, größtenteils zurecht. Hätten sie besser kommuniziert (weniger defensiv, ohne Auslassung zeitlicher/ursächlicher Zusammenhänge etc.), wäre das sicherlich besser aufgenommen worden. Aber es war trotzdem zu spät, die bereits erfolgte Berichterstattung war kaum noch einzufangen.

        1. Die ETH bzw. der Professor hat auf Twitter zusätzlich der Darstellung, dass die gefundenen Schwachstellen unrealistische Vorraussetzungen benötigen (siehe Blog des Entwicklers: https://blog.dbrgn.ch/2023/1/14/threema/#attack1) sehr Früh wiedersprochen ohne Konkret zu werden. Er sagte einfach, das sei Falsch und ganz ohne seine Behauptung zu belegen, was nicht sehr wissenschaftlich ist.

  2. Danke für den spannenden Artikel und die Referenz zu meinem Vortrag. Die konkrete Anwendung auf die Beispiele zeigt die Schwächen der Krisenkommunikation bei den beiden Fällen schön auf. Leider werden bei ähnlichen Vorfällen immer noch viel zu oft die Basics der Krisenkommunikation missachtet.

  3. Der Threema-Fall zeigt meiner Meinung nach auch den Qualitätsverlust der Medien. Eine wichtige Aufgabe von Journalisten ist die Einordnung. Nicht, einen reisserischen Artikel zu schreiben (womöglich mit Totenkopf auf dem Titelbild), sondern den Lesern zu erklären, wie die Sache einzuordnen ist. Wenn man dazu die Fachkompetenz nicht hat, fragt man einen Experten.

    Man sah das auch bei Spectre und Meltdown: Überall Artikel „Dein PC ist nicht mehr sicher!!!“, dabei ist das Ausnutzen der Lücken extrem komplex. Dafür sind echte, in der Realität ausgenutzte Lücken wie in den Browsern von Android und iOS nur eine Randnotiz wert: „iOS 16.1 schliesst diverse Sicherheitslücken“.

    Dass nicht nur Online-„Klickschlampen“-Medien dabei versagen, sondern sogar die NZZ, macht mich traurig. Fehler in IT-Artikeln erkenne ich (hoffentlich) meist, aber auf solche Medien kann ich nicht vertrauen, da ich davon ausgehen muss, dass bei anderen Themen, von denen ich weniger verstehe, die Einordnungsleistung genauso schlecht ist. Dieses Problem sehen leider viele Medien nicht und verspielen munter weiter Vertrauen für ein paar Klicks auf aufgebauschte Artikel.

  4. Die Angaben von Threema sind irreführend. Die Angriffe sind sehrwohl realistisch.

    1. Der ganze Witz eines solchen Messengers ist, dass der Zweck der Verschlüsselung ist, vor dem Serverbetreiber zu schützen. Wenn man dem trauen könnte, bräuchte man keine Ende-zu-Ende-Verschlüsselung.

    2. Threema spricht vom alten Protokoll. Das neue wurde aber gerade erst seit kurzem eingeführt, so alt ist das alte Protokoll nicht. In dem alten Protokoll waren die Schwächen viele Jahre enthalten. Das ist aber auch kein Zufall, denn es gehört zu den guten Sitten, dass Sicherheitsforscher die Details erst veröffentlichen, wenn die Probleme gelöst wurden.

    3. Viel wichtiger als die einzelnen Lücken ist der Gesamteindruck. Es sind im Protokoll viele Anfängerfehler und No-Gos enthalten. Sie haben viel unnötig selbstgebastelt, statt auf gut erforschte Protokolle zu bauen. Manche dieser Angriffe (Nachrichten verschwinden zu lassen oder umzusortieren) sind absolute Standardszenarien, gegen die ein Messenger schützen muss. Das sind Haushaufgaben, die da nicht gemacht wurden. Das ist für so eine Firma, die sich als besonders sicher zu verkaufen versucht, nicht angemessen.

    Der dritte Punkt wird aber etwas entschärft dadurch, dass in der Anfangszeit von Threema noch nicht alles, was heute Standard ist, Standard war. Die Einordnung der NZZ, dass sie hier mittlerweile Jahre hinterher hingen, ist allerdings nicht von der Hand zu weisen.

    1. @Stephan: Aufgrund Ihrer Aussagen scheinen ein paar Missverständnisse vorzuliegen.

      1. Die Ende-zu-Ende-Verschlüsselung dient dazu, Inhalte vor Dritten zu schützen – auch dem Betreiber des Servers. Im Fall von Threema war das immer gewährleistet.

      2. Sie sprechen von „Schwächen“. Das waren keine Schwächen, sondern kryptografische Eigenschaften, die das alte Protokoll nicht geboten, aber auch nie versprochen hat. Man kann natürlich darüber streiten, was heutzutage als „need-to-have“ gelten soll. Da gibt es kein richtig oder falsch, sondern letztlich ist es eine Frage des Bedrohungsmodells (gegen welche Angriffe das Protokoll schützen soll) und der Prioritäten – bei Threema scheint das eher die Privatsphäre zu sein.

      3. Das ist schlichtweg falsch. Die Kryptographie von Threema war und ist absoluter Standard und „gut erforscht“ (NaCl und CurveCP) und in der Implementation wurden keine Fehler gefunden.

      Korrekt ist, dass Threema nicht gegen „Nachrichten verschwinden zu lassen“ oder „umsortieren“ durch einen Angreifer, der sich Zugang zum Server verschafft hat, schützte. Doch wie wichtig ist das wirklich? Der Angreifer hat aufgrund der Ende-zu-Ende-Verschlüsselung gar keine Einsicht in die Inhalte der Nachrichten und weiss deshalb gar nicht, was er da umsortiert.

      1. Sorry, aber das Umsortieren von Nachrichten ist nicht nice-to-have. Das ist essentiell. Sonst kann man einfach Ja und Nein vertauschen …

        1. „Einfach“ schon gar nicht.

          Ein Angreifer (der sich zuerst mal unbemerkt auf dem/n Server/n eingenistet haben muss) weiss nicht, in welcher Nachricht sich „Ja“ und „Nein“ befinden und von wem an wen eine Nachricht geht, weil er den Inhalt und die Metadaten aufgrund der Ende-zu-Ende-Verschlüsselung nicht lesen kann. Kommt noch dazu, dass er sowas nur abziehen kann, wenn sich die zu vertauschenden Nachrichten gleichzeitig auf dem Server befinden. Bereits abgelieferte Nachrichten kann er nicht vertauschen.

          Aber ja, es wäre theoretisch möglich gewesen, nur nicht machbar.

          PS: Der oben verlinkte Blog-Post eines Threema-Mitarbeiters hilft enorm, die Voraussetzungen und tatsächlichen Implikationen zu verstehen.

  5. Ein paar Gedanken zur Kommunikation (vom Technischen habe ich zu wenig Ahnung)

    Ja, das Zuspitzen war einst Stilmittel eines journalistischen Beitrages, heute ist schon fast Standard. Ich erkenne an dem Bericht der NZZ zur Threema-Schwachstelle keine Mängel. Im Gegenteil: Es wir eingeordnet, erklärt, es werden Spezialisten und Threema angehört. Was mit dem Ausnützen der Schwachstelle angestellt werden kann und schreibt auch, dass es für einen Angreifer schwierig wäre, die Schwachstelle auch wirklich auszunutzen. Aber der Bericht deckt halt die Schwachstelle der Kommunikation von Threema auf.

    Wer wie Threema mit „maximaler Sicherheit beim Chatten. Beruflich und privat“ (Title-Tag der Webseite) wirbt, von dem wird erwartet, dass man die maximale Sicherheit erhält und das war halt nicht so. Oder anders gesagt: Wer mit Superlativen um sich wirft, der wird an ihnen gemessen. Die kleinste Abweichung kann dann zur Krise werden. Während die Marketing-Kommunikation im Wind der Schönwetterkommunikation segelt, erhöht das den Chill-Factor der Krisenkommunikation. Denn aus Superlativen kann ich mich nicht rauswinden, wenn ich nicht super war, letztlich habe ich mein Versprechen nicht eingelöst. Da hilft die sachliche Erklärung dann wenig,
    um die emotionale und moralische Ebene zu beschwichtigen. Oder – man verzeihe mir die Zuspitzung – Wer mit Superlativen wirbt, hat in der Krisenkommunikation bereits verloren.

    Ein anderer Aspekt, dem wohl von beiden Unternehmen zu wenig Rechnung getragen wurde (ich kann es nur vermuten) ist, dass sie sich nicht auf ihr Top-Reputationsrisiko vorbereitet hatten. Wer Sicherheit anbietet weiss einerseits, dass es keine absolute Sicherheit gibt und andererseits, dass das Thema darum irgendwann aufkommen und dieses zum Top-Risiko der Reputation wird. Zumindest, wenn es den Kern-Nutzen der Marke darstellt. Ein Reputationsschaden ist in einem solchen Fall auch nicht gänzlich zu verhindern (auch hier gilt, es gibt keine absolute Sicherheit), aber man kann ihn eindämmen, indem man sich darauf vorbereiten und übt, was man tut, wenn es denn mal eintritt. Das ist anstrengend und im Stress des Alltags schnell wegpriorisiert – weil halt kein unmittelbares Risiko (man erkenne die Rekursion).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Beiträge