Suche
Close this search box.

Responsible Disclosure, ein seeeehr breiter Begriff

Am 9. Januar 2023 publizierte eine Forschungsgruppe der ETH auf einer eigens dazu aufgesetzten Webseite eine Reihe von Schwachstellen, welche ein Master-Student in der Messenger-App Threema entdeckt hat. Gleichentags publizierte das Unternehmen selbst eine Stellungnahme zu den Schwachstellen. Auffällig dabei war neben der völlig unterschiedlichen Einschätzung der Relevanz und «Gefährlichkeit» der Schwachstellen die teilweise recht aggressive wirkende Kommunikation zwischen Forschern und Unternehmen. Für die Öffentlichkeit war das ziemlich überraschend, und es führte zu einem kleinen Shitstorm in den sozialen Medien und zu teilweise heftiger Kritik aus Security-Kreisen. Soweit die Story, wie wir sie kennen. In den letzten Wochen sind wir aber über ein Detail gestolpert welches in dieser Form noch nicht bekannt war.

Einer der grossen Threema-Anwender in der Schweiz ist das Schweizer Militär, welches den Messenger allen Armee-Angehörigen zur Verfügung stellt. Wir wollten daher vom VBS wissen, wie sie mit den Informationen über die Schwachstellen umgegangen sind und welche Konsequenzen sich daraus für den Einsatz ergeben und haben die entsprechenden Dokumente auf Basis des Bundesöffentlichkeitsgesetz (BGÖ) angefordert. Neben Antworten auf diese Fragen haben wir dabei auch Details zur Kommunikation zwischen ETH, Threema und VBS erhalten, und diese Details haben es in sich:

  • Am 3. Oktober 2022 nimmt die ETH-Gruppe mit Threema Kontakt auf und stellt dem Unternehmen die Liste der gefundenen Schwachstellen zu.
  • Threema schlägt gleichentags ein Treffen vor, um Behebungsmassnahmen und das Vorgehen für ein «Responsible Disclosure» zu besprechen.
  • Zwei Tage später findet ein Treffen zwischen der ETH-Gruppe und Vertretern des VBS statt, an welchem die ETH-Gruppe dem VBS die Findings vorstellt. In der Zusammenfassung der Slides, die bei diesem Treffen dem Threema-Kunden VBS gezeigt werden, wird nicht mit Kritik an der App gespart: «Threema is a fundamentally flawed application».
  • Erst am 13. Oktober kommt es dann zum am 3. Oktober angeregten Treffen zwischen der ETH-Gruppe und Threema. An diesem Meeting erfahren die teilnehmenden Threema-Vertreter auch, dass das VBS bereits direkt kontaktiert wurde.
  • Am nächsten Tag kommt es bezüglich der Schwachstellen dann erstmals zu einem Direktkontakt zwischen Threema und VBS, am 16. Oktober nimmt Threema in einer ausführlichen Analyse (die weitgehend der am 9. Januar veröffentlichen Version entspricht) Stellung.

Dieser zeitliche Ablauf wurde uns sowohl von Threema wie auch der ETH-Gruppe bestätigt. Kenny Paterson von der ETH sieht darin kein Problem, aus seiner Sicht ist «Responsible Disclosure» ein breiter Begriff, mit dem die Balance zwischen sofortiger Publikation und Geheimhaltung gefunden werden muss. Im konkreten Fall sah er es in seiner Verantwortung als Bundesangestellter, den Bund bzw. das VBS direkt zu informieren. Dass andererseits ein Software-Hersteller wenig Freude daran hat, wenn Dritte hinter seinem Rücken seine Kernapplikation gegenüber einem Kunden als “fundamentally flawed” bezeichnet, liegt wohl ebenso auf der Hand.

Was ist nun dieses «Responsible Disclosure»?

Offenbar kann man unter «Responsible Disclosure» Verschiedenes verstehen, wir haben uns auf die Suche nach der Begriffsdefinition gemacht. Die englischsprachige Wikipedia verweist für den Begriff auf «Coordinated vulnerability disclosure», die deutschsprachige Version definiert den Begriff als “ein Verfahren zur Offenlegung von Sicherheitslücken, bei dem die Schwachstelle zuerst den Entwicklern gemeldet und erst nach einer angemessenen Frist zur Behebung veröffentlicht wird”. Auch andere Definitionen des Begriffs unterscheiden nur zwischen der Bekanntgabe zuhanden des Herstellers/Entwickler und der breiten Veröffentlichung, zu einer allfälligen Vorabinformation Dritter lässt sich nichts konkretes finden. Der Begriff scheint also in der Tat verschieden verstanden zu werden können.

Wir haben mit einigen Sicherheitsforschern in der Schweiz über ihr Verständnis von «Responsible Disclosure» gesprochen, die Meinungen über die Bedeutung des Begriffs gehen definitiv auseinander. Einer der befragen Forscher stellt sich klar auf den Standpunkt, dass es im obigen Fall nicht um «Responsible Disclosure» handelt. Laut ihm wäre allenfalls ein «Coordinated Disclosure» denkbar gewesen, aber auch dies nur unter der Voraussetzung, dass die ETH-Gruppe Threema vorab darüber informiert, dass die Informationen während der Stillhaltefrist an ausgewählte Dritte weitergegeben werden. Dazu hätten die gefundenen Schwachstellen aber derart offensichtlich sein müssen, dass davon auszugehen gewesen wäre, dass sie bereits ausgenutzt werden.

Anders sieht es Christian Folini, der in den letzten Jahren Bund und Post beim eVoting beraten hat. Für ihn sind «Coordinated Disclosure» und «Responsible Disclosure» keine klar definierten Verfahren, das Ziel sollte primär sein, dass man einem Hersteller Zeit gibt, einen Fehler zu beheben bevor die Schwachstelle der Öffentlichkeit mitgeteilt wird. Er sieht gerade in der Schweiz eine Tendenz, von einer Sicherheitsforscherin zu verlangen, dass sie während dieser Zeitperiode mit gar niemandem ausser dem Hersteller über eine Schwachstelle sprechen dürfen. Dafür gebe es allerdings keine Grundlage, schliesslich stehen Forscherin und Unternehmen nicht in einer vertraglichen Beziehung. Im konkreten Fall sei die Schweizerische Eidgenossenschaft immerhin ein wichtiger Kunde von Threema und stütze sich namentlich in der Krisenkommunikation stark auf dieses Tool ab. Über Schwachstellen informiert zu sein berührt damit mithin die nationale Sicherheit, eine zeitnahe Benachrichtigung des VBS oder generell der entsprechenden Stellen des Bundes könne man daher vertreten.

Wie können es Unternehmen besser machen?

Als sehr vereinfachtes Fazit könnte man sagen, dass Kommunikation schwierig ist, vor allem wenn mehr als eine Person involviert ist. Konkret gilt es dem Umstand Rechnung zu tragen, dass beim Bekanntmachen von Sicherheitslücken verschiedene Interessen im Spiel sind und dass diese Interessen weder deckungsgleich noch gleichgerichtet sein dürften.

Als möglichen Ausweg schlägt Folini Bug Bounty-Programme vor, mit welchen Unternehmen Sicherheitsforscher dazu motivieren können, allfällige Schwachstellen gezielt zu melden und sich, üblicherweise gegen einen von der Schwere der Lücke abhängigen Geldbetrag, zu Stillschweigen zu verpflichten. Damit sinkt für Sicherheitsforscher auch das Risiko, für ihre versuchten oder erfolgreichen Angriffe vor Gericht zu landen (auch wenn das im Falle der ETH-Gruppe wohl eher vernachlässigbar gewesen ist). Solche Bug Bounty-Programme kann man im einfachsten Fall direkt auf der eigenen Webseite anbieten, vermutlich fährt man aber besser wenn man dazu mit einem entsprechenden Dienstleister zusammenarbeitet der einem hilft, typische Fallstricke zu vermeiden, und der sich auch um administrative Details kümmert.

Nachtrag: Im konkreten Fall hat das allerdings nix genützt, Threema hat bereits ein Bug Bounty-Programm.


PS: Um zum Schluss noch auf die Frage zurückzukommen, wie das VBS mit den ihm im Oktober gemeldeten Schwachstellen umgegangen ist: Die Antwort dazu findet sich in den uns aufgrund des BGÖ-Gesuchs zugestellten Dokumenten:

  • Im November nahm das VBS eine eigene Analyse der Schwachstellen sowie der von Threema geplanten Verbesserungen vor, und kam zum Schluss, dass «We […] consider this reactions appropriate, since most of the weaknesses revealed in your paper will be mitigated with these intended fixes»
  • Auch der NDB untersuchte die Schwachstellen und hielt Ende November in einer Aktennotiz fest, dass die beschriebenen Attacken auf die gemäss ETH-Gruppe «fundamentally flawed» App theoretischer Natur und in der Praxis kaum/nur mit sehr hohem Aufwand umsetzbar sind, selbst für Nachrichtendienste mit grossen Ressourcen. Aus einer Perspektive der Risikobetrachung sieht er in der Hardware-Plattform (also dem jeweiligen Smartphone) das grössere Risiko als in den theoretischen Angriffen auf das Threema-Protokoll oder den Threema-Server. Er (der NDB) sah daher keinen Grund, vom Einsatz von Threema in der Bundesverwaltung abzuraten.

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.

14 Antworten

  1. Vielen Dank für den spannenden und differenzierten Artikel! Bestimmt wäre es hilfreich, wenn sich die ETH hierzu ein paar Guidelines gäbe, damit allen klar ist, wie so eine Disclosure zwischen “abhängigen Unternehmen” (ETH / Bundesverwaltung) und Beauftragten (Threema) ablaufen soll. Dass die Arbeit der ETH an sich aber unabdingbar ist, versteht sich von selbst…

    1. Der Hersteller hat gar keine Ansprüche. Reporting und Disclosure dienen dem Schutz der Nutzer und der Allgemeinheit. Der Hersteller kann froh sein, dass er in der Regel nicht für Fahrlässigkeit haften muss.

      1. > Reporting und Disclosure dienen dem Schutz der Nutzer

        Und die Lücke dem Geheimdienst und Militär weiter zu reichen dient ebenfalls dem Schutz der Nutzer? Würden amerikanische forschende die Lücken zeitlich dem Herstellung und der NSA Melden wäre das ein Skandal in allen Medien. Da es in diesem Fall “nur” das VBS und der NDB ist, ist alles Butter… Verkehrte Welt.

      2. Ich habe stark den Eindruck diese Sicht ist sehr einseitig (gegen den Hersteller) und lässt ein paar Dinge ausser acht.

        Hätte der Hersteller fahrlässig gehandelt, wären die daraus entstandenen Sicherheitslücken wohl A) schon viel früher entdeckt worden und B) weit signifikanter als nur “theoretischer Natur” (gemäss NDB).

        Ein Hersteller hat nicht Ansprüche im konkreten Sinn. Allerdings sollte er sich darauf verlassen können, dass Forscher und Sicherheitsanalysten mit der Motivation antreten eine bestimmte Software sicherer für alle zu machen. Das ist das “responsible” and “responsible disclosure”. Ich bin ziemlich überzeugt, dass die ETH Truppe nicht in diese Kategorie fällt, doch mir begegnen auch immer wieder Veröffentlichungen von sogenannten Experten, die wenig Fleisch am Knochen haben resp. sehr esoterische Lücken beschrieben oder schlicht falsch sind. Diese Art von Veröffentlichungen können, wenn sie von main stream Medien aufgegriffen werden, für Hersteller rufschädigend sein und somit die Grundlage für Forderungen der Herstellen bieten.

        1. Die Einschätzung des NDB ist erschreckend. Ohne jetzt die Forscher der ETH genauer zu kennen, wo war die Enthüllung hier unverantwortlich? Haben sie etwas veröffentlicht, bevor es behoben wurde bzw. werden konnte?

  2. Es geht bei der ganzen Sache nicht um die Sicherheitslücken. Es geht vielmehr darum, dass die Sicherheitslücken zeigen, dass Threema eben wirklich «fundamentally flawed» ist. Die Art der Lücken geben den Eindruck, dass Threema sich nichtmal ein paar Stunden damit beschäftigt hat, was eigentlich die Basisanforderungen für einen sicheren Messenger nach Stand der Technik waren.

    Beispiel:
    Sie sagen, manche der Angriffe könnten nur durchgeführt werden, wenn der Angreifer den Server kontrolliert. Dieses Szenario ist der ganze Sinn von Ende-zu-Ende-Verschlüsselung. Wenn der Server sicher wäre, dann würde auch einfaches TLS vom Client zum Server reichen. Ende-zu-Ende-Verschlüsselung soll ja gerade das Lesen der Nachrichten durch den Betreiber, Einbrecher oder staatliche Durchsuchungen schützen.

    Und das ist unter dem Hintergrund, dass sie für ein anderswo kostenloses Produkt extra Geld nehmen und als extra sicher bewerben und auch damals nichtmal den Quelltext offenlegten, so ein Armutszeugnis, das grenzt schon an Betrug. Und es ist auch ein ziemlicher Skandal, dass sie so einen Schrott mit selbstgebastelter Kryptographie von Amateuren an das Schweizer Militär verkauft haben.

    Und dass sie direkt zum VBS gegangen sind, ist auch okay. Der Hersteller hat überhaupt keinen Anspruch auf irgendwas. Wenn man Lücken an Hersteller meldet, dann tut man dies zum Schutz seiner unschuldigen Kunden, nicht zur Rettung des Herstellers. Böse an der Weitergabe an VBS ist nur, dass der Bund diese Lücken gegen andere Threema-Nutzer ausnutzen könnte.

    Und es ist auch völlig in Ordnung, wenn ein Nutzer einen Messenger als Schrott bezeichnet, insbesondere wenn er ein unabhängiger Experte ist, der selbst kein Konkurrenzprodukt verkauft.

    1. Nachtrag: Bug Bounties werden übrigens von vielen insbesondere bekannte Sicherheitsforschern genau wegen der Bedingungen wie Schweigepflicht abgelehnt.

      1. Und so undefiniert ist das ganze nicht, es gibt ISO 29147 und ISO 30111 zum Thema.

        Zitat dazu:
        These standards make clear that private bug bounty NDAs are not ISO compliant. “When non-disclosure is a required term or condition of reporting bugs via a bug bounty platform, that fundamentally breaks the process of vulnerability disclosure as outlined in ISO 29147,” Moussouris says. “The purpose of the standard is to allow for incoming vulnerability reports and [her emphasis] release of guidance to affected parties.”
        ISO 29147 lists four major goals, including “providing users with sufficient information to evaluate risk due to vulnerabilities,” and lists eight different reasons why publishing security advisories is a standardized requirement, including “informing public policy decisions” and “transparency and accountability.” Further, 29147 says that public disclosure makes us all more secure in the long term. “The theory supporting vulnerability disclosure holds that the short-term risk caused by public disclosure is outweighed by longer-term benefits from fixed vulnerabilities, better informed defenders, and systemic defensive improvements.”
        https://www.csoonline.com/article/3535888/bug-bounty-platforms-buy-researcher-silence-violate-labor-laws-critics-say.html

        Im Artikel sind auch noch interessante Aspekte wie der Konflikt mit Arbeitnehmerrechten und Datenschutz.

        Und hier noch ein Erfahrungsbericht der Schweizer Firma Modzero zum Thema:
        https://modzero.com/modlog/archives/2022/08/22/ridiculous_vulnerability_disclosure_process_with_crowdstrike_falcon_sensor/index.html

        1. Vermischen wir hier jetzt nicht “No Disclosure”, “Full/Immediate Public Disclosure” und “Delayed Public Disclosure”? Dass Security-Probleme spätestens dann publiziert gehören wenn der Fix/Patch des Herstellers vorliegt ist IMHO unbestritten. Aber dem Hersteller eine kurze Frist von 30 oder 90 Tagen zubilligen um Issues zu fixen, scheint mir je nach betroffenen Produkt und effektiver Lücke nicht ganz falsch zu sein. Die Balance zwischen “Nutzer frühstmöglich warnen” und “Nachahmungstäter füttern” muss man da allerdings jeweils abhängig von der Lücke finden, da gibt es kein simples Schwarz oder Weiss.

          1. Da stimme ich dir zu, und wir sind ansonsten auch glaube ich weitgehend derselben Meinung. Nur bei Threema eben nicht. 🙃

    2. @Stephan:
      Von einer Möglichkeit, auf dem Server Nachrichten mitzulesen wie bei TLS war in dem Paper gar nicht die Rede. Davor schützt die (nein, nicht selbstgebastelte) Ende-zu-Ende-Verschlüsselung wirksam. Es ging lediglich um Reordering und Omission. Aber auch sonst steckt etwas zu viel gefährliches Halbwissen in deinem Beitrag.

      1. Replay und Reordering sind DIE Standardangriffe gegen verschlüsselte Kommunikation. Der Angreifer kann die Nachrichten «Ja» und «Nein» abfangen und bei Bedarf einsenden und die Reihenfolge verändern.
        Das wird seit eh und je als Totalschaden für einen verschlüsselten Messenger betrachtet. Vor 15 Jahren haben wir schon im Studium einen verschlüsselten Messenger als Hausaufgabe in einem Semester programmiert und dann selbst gegenseitig angegriffen. Das ist wirklich absolutes Grundlagenwissen.
        Von einer Firma, die sich so als qualitätsbewusst und besonders sicher darstellt, hätte ich erwartet, dass sie wenigstens eine Person im Team haben, die so ein Grundlagenwissen hat. Die gefundenen Lücken lassen aber eher darauf schliessen, dass absolutes Grundwissen fehlte.

        Und ob die ETH-Forscher am Ende die Lücke als praktisch oder theoretisch bezeichnet ist ihre eigene Sicht und Meinung, dadurch wird eine Veröffentlichung nicht unverantwortlich. Unverantwortlich wäre es nur, vereinbarte Fristen zu ignorieren. Das ist meines Wissens nicht geschehen. Anspruch auf Mitsprache bei der Form der Veröffentlichung hat der Hersteller nicht, und gute Forscher werden sich da auch nie zu verpflichten lassen.

Schreibe einen Kommentar

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

Weitere Beiträge