Internetgeschichten Teil #15 – Wie ein Matrix-Fehler die Verschlüsselung im Bundeswehr-Messenger aushebelte

Wir haben uns hier im Blog ja schon einige Male mit verschiedenen Messenger-Produkten und ganz besonders mit dem Thema „Ende-zu-Ende-Verschlüsselung“ beschäftigt. Diese ist die Voraussetzung für einen Nachrichtenaustausch, bei dem niemand heimlich mitlesen kann. Allerdings sollte man nicht den Fehler machen, sich vollständig darauf zu verlassen. Heute will ich an einem aktuellen Beispiel erklären, wie Schwachstellen in den Produkten ausgenutzt werden können. Gerade erst kursierte die Meldung, dass es im Messenger-Protokoll „Matrix“ Sicherheitslücken gibt, die ein heimliches Mitlesen von vermeintlich verschlüsselten Chat-Nachrichten möglich machen.

Matrix ist sicher nicht so bekannt wie WhatsApp. Es ist eigentlich auch mehr ein Baukasten für verschiedene Messenger-Produkte. Mit 60 Millionen Benutzern ist Element (früher „Riot“) vermutlich das mit der mit der größten Reichweite. Bei uns in Deutschland interessieren sich das BSI und verschiedene Bundesbehörden auch stark dafür. Man sieht es dort nicht gerne, wenn vertrauliche Nachrichten über ausländische Server austauschen. So hat zum Beispiel auch die Bundeswehr einen eigenen Messenger („bwmessenger“) für ihre Mitarbeiter entwickelt. Bei der Bundeswehr-IT hat man eine hohe Meinung von Matrix. Auf deren Webseite zum bwmessenger (https://messenger.bwi.de) liest man an erster Stelle:

Die Lösung basiert auf dem Open-Source-Protokoll Matrix und wurde für maximale Sicherheit konzipiert. Die Kommunikation ist durchgängig verschlüsselt und deine Daten werden ausschließlich auf gesicherten Servern der Bundeswehr gespeichert – persistent und mit deinem privaten Schlüssel codiert.

Das soll im Prinzip sagen „Ihr könnt mit dem bwmessenger über unsere Server chatten, wir können nicht mitlesen.“ Am 28.9.2022 gaben jedoch die Matrix-Entwickler in ihrem Blog eine Warnung heraus, dass genau diese durchgängige Verschlüsselung aufgrund von Fehlern in der Software umgangen werden kann, wenn man Zugriff auf den Server hat. Herausgefunden hat das eine Gruppe von Cybersicherheitsexperten der Universitäten von London und Sheffield sowie der Firma Brave Software. Die komplette wissenschaftliche Arbeit kann man hier einsehen, ist aber nicht einfach zu lesen, gespickt mit mathematischen Formulierungen und konventionellen Bezeichnungen, die man als Laie nicht kennen muss. Um dennoch einen Eindruck zu vermitteln, wie der der „Hack“ funktioniert, folgt nun eine etwas anschaulichere Erläuterung.

Wo sind die Schwachstellen in Matrix-Produkten wie Element und bwmessenger?

Wir stellen uns Alice und Bob vor, die per Messenger-App auf dem Smartphone miteinander kommunizieren wollen. Zusätzlich haben wir noch die neugierige und moralisch zweifelhafte Mallory. Mallory hat Zugriff auf den Matrix-Server, über den die Nachrichten zwischen Alice und Bob übertragen werden. Vielleicht einfach über ihren Job, möglicherweise hat sie sich aber auch dort zunächst über eine andere Sicherheitslücke eingebrochen. (Die Namen sind beliebt bei Informatikern zur Erläuterung solcher Dinge und werden auch von den Wissenschaftlern in der Arbeit verwendet, daher übernehme ich das heute einmal.)

Eine erste Sicherheitslücke könnte Mallory sehr einfach ausnutzen: In Matrix sind alle Chats als Gruppen organisiert, auch wenn es nur zwei Teilnehmer gibt. Der von ihr kontrollierte Server organisiert die Teilnehmer jeder Gruppe und Mallory könnte ohne Mühe einen weiteren Gruppenteilnehmer hinzufügen. Die Matrix-Entwickler sehen das nicht so tragisch und argumentieren, dass Alice und Bob ja die Teilnehmer einer Gruppe jederzeit einsehen können. Die Sicherheitsanalysten argumentieren wiederum, dass Benutzer dies leicht übersehen können, vor allem in Gruppen mit vielen Teilnehmern. Das ist dann wohl Ansichtssache, wir halten uns raus. Mallory will ohnehin kein Risiko eingehen und sucht daher nach einer subtileren Methode.

Sie weiß, wenn Alice und Bob mit aktiver Ende-zu-Ende-Verschlüsselung Nachrichten miteinander austauschen, hat sie keine Chance. Die Nachrichten kann sie während der Übertragung zwar auf dem Server sehen, aber deren Inhalte nicht entschlüsseln. Sie erkennt nur Buchstabensalat. Die zum Entschlüsseln der Nachrichten notwendigen privaten Schlüsselinformation sind auf den Smartphones von Alice und Bob gespeichert. Da kommt Mallory nicht dran. Sie überlegt daher: „Ich müsste irgendwie Bob gegenüber vortäuschen, Alice zu sein. Und andersherum müsste Alice glauben, dass ich Bob bin. Dann würden mir die beiden ihre Nachrichten senden, ich könnte sie lesen und anschließend jeweils an den richtigen Empfänger weiterleiten, damit es nicht auffällt“. Diesen Angriff auf die Privatsphäre von Alice und Bob nennt man klassisch „Man-in-the-middle“ und haben wir hier auch bereits mit anderen anschaulichen Beispielen behandelt.

Wie umgeht man eine Ende-zu-Ende-Verschlüsselung?

Um die Man-in-the-middle-Position einzunehmen, gibt es für Mallory nur eine Gelegenheit, nämlich ganz zu Beginn, wenn sich die Smartphones von Alice und Bob miteinander in Verbindung setzen, noch bevor die Verschlüsselung aufgebaut ist. Hier müssen die Smartphones sich gegenseitig beweisen, dass sie wirklich sie selbst sind und dass sie sich gegenseitig vertrauen. Es ist ein bisschen wie eine Fernhochzeit, bei der man sich nicht persönlich trifft, sondern nur die Trauungspapiere zum Unterzeichnen zusendet. Bei solch einer digitalen Ehe handelt es sich bei den „Trauungspapieren“ um eine elektronische Nachricht mit den jeweiligen Schlüsselinformationen der beiden Partner (engl. „Key Message“). Das ist ein heikler Prozess, denn erst nach Erhalt der Schlüssel wissen die beiden Smartphones, wie sie dauerhaft mit einer sicheren Ende-zu-Ende-Verschlüsselung arbeiten können. Bei der Key Message selbst, kann sie somit noch nicht verwendet werden. Da die Key Message wie alle anderen Chat-Nachrichten über den Matrix-Server läuft, könnte Mallory demnach die Nachricht von Alice an Bob abfangen und stattdessen eine vorgetäuschte Key Message der falschen Alice senden. Bob würde dann sozusagen die falsche Frau heiraten.

Geh doch woanders hin: Verschlüsselung außer Rand und Band

Doch so einfach geht es dann doch nicht. Über diese Gefahr waren sich die Matrix-Entwickler natürlich bewusst. Damit auch die Key Messages mit einer sicheren Verschlüsselung übertragen werden und um sicherzustellen, dass es sich bei den Absendern wirklich um Alice bzw. Bob handelt, können die beiden ein einen einmalige geheimen Schlüssel vereinbaren und den Nachrichten mitgeben. Das ist im Prinzip ein Codewort, welches sie aber nicht über den Matrix-Server austauschen dürfen, sonst könnte Mallory dies ja auch abfangen. Stattdessen kann es telefonisch oder bei einem persönlichen Treffen geschehen. Messenger-Apps bieten hierzu auch gerne das gegenseitige Scannen eines QR-Codes an. Wie genau Alice und Bob den Code austauschen ist eigentlich egal, hauptsache es geschieht nicht über den von Mallory kontrollierten Server. Diese „Irgendwo-anders“-Übertragung einer geheimen Information bevor man die eigentliche Kommunikation beginnt, nennen wir „Out-of-band“ (engl. für „Außerhalb des Bandbereichs“, was wiederum seinen Ursprung im Funkverkehr hat).

Sicherheit in Software: Theoretisch perfekt, praktisch defekt

An diesem Punkt enden üblicherweise theoretische Sicherheitsanalysen zum Matrix-Protokoll. Denn in der Theorie ist das Verfahren sicher. Im Konzeptpapier hat man auf alle Angriffsmöglichkeiten eine passende Antwort. Doch Mallory weiß: In der Realität müssen Software-Entwickler das Konzept in komplizierten Computerprogrammen umsetzen. Und in der Praxis passieren beim Programmieren immer Fehler. Das Matrix-Programm ist kein Firmengeheimnis wie zum Beispiel WhatsApp. Matrix ist „open source“ (engl. „quelloffen“), d.h. jede Zeile des Programms ist öffentlich einsehbar. Das soll Vertrauen schaffen und die Mitarbeit möglichst vieler Helfer ermöglichen. Viele Augen finden schneller die Fehler im Programm und sorgen langfristig für eine bessere Qualität. Allerdings hat dadurch auch Mallory die Möglichkeit, gezielt nach Fehlern zu suchen, die sie für ihre Zwecke ausnutzen könnte. Und sie wird fündig.

Die Hauptakteure im Matrix-Programm

Auf den Smartphones von Alice und Bob läuft ein Unterprogramm (nennen wir es hier „VERIFY“), welches für die Prüfung der empfangenen „Trauungspapiere“ bzw. Key Message zuständig ist. Hier wird ermittelt, ob der out-of-band ausgetauschte Code korrekt ist. Ist das der Fall, beginnt die Unterschriftsprozedur. Hierbei liest VERIFY auf Alice‘ Smartphone aus der von Bob empfangenen Key Message dessen Benutzerkennung aus. Das ist eine eindeutige Kennnummer, sozusagen Bob’s digitale Identität. Damit kann VERIFY den richtigen Benutzer identifizieren, mit dem die digitale Hochzeit stattfinden soll. Die eigentliche Trauung überlässt VERIFY aber einem zweiten Unterprogramm namens „SIGN“. SIGN führt im Namen von Alice eine digitale Signatur auf Bobs Benutzerkennung durch. Damit bestätigt Alice, dass sie allen Nachrichten von dieser Benutzerkennung vertrauen wird … in guten wie in schlechten Zeiten. Der gleiche Prozess findet umgekehrt auf Bobs Smartphone statt. Die gegenseitige Signatur der Benutzerkennungen ist die Basis für die Ende-zu-Ende-Verschlüsselung.

Soweit sogut. Doch bei der genaueren Betrachtung wird Mallory stutzig, denn sie findet in beiden Unterprogrammen mehr Zeilen als erwartet. Bevor VERIFY nach einem Benutzer mit der gegebenen Kennung sucht, führt es eine Suche nach Smartphones oder anderen Geräten mit derselben Kennung durch. Warum das denn? Neben der Beziehung zwischen zwei Benutzern, gibt es noch eine zweite Art „Ehe“, nämlich zwischen Benutzern und ihren Geräten (Smartphones, Tablets, Notebooks, etc.). Möchte ein Benutzer ein zweites Gerät zum Chatten registrieren, kann er die oben beschriebene Hochzeitsprozedur mit seinem ersten Gerät durchführen. In diesem Fall empfängt Gerät 1 die Key Message von Gerät 2 und umgekehrt. Das Unterprogramm VERIFY startet wieder, ermittelt Gerät 2 anhand der Gerätekennung und übergibt an SIGN. Dort wird die Kennung von Gerät 2 im Namen des Benutzers signiert. Damit bestätigt der Benutzer, dass es sich um ein eigenes Gerät handelt.

Das Verwirrspiel der Matrix-Unterprogramme

Key Messages werden also in zwei ähnlichen, aber nicht identischen Prozessen verwendet. Wir haben auf der einen Seite das gegenseitige Signieren zwischen zwei Benutzern (sog. „Cross Signing“) und auf der anderen Seite das Signieren eines neuen Geräts durch einen Benutzer (sog. „Device Verification“). Im ersten Fall verarbeiten VERIFY und SIGN eine Benutzerkennung, im zweiten Fall eine Gerätekennung. „Interessant“, denkt sich Mallory, „die Matrix-Entwickler haben es sich an dieser Stelle einfach gemacht. In den Key Messages sind immer beide Kennungen enthalten. VERIFY und SIGN müssen immer raten, um welchen der beiden Prozesse es sich handelt. Vielleicht kann ich das ausnutzen, um die beiden Unterprogramme zu verwirren.“

Mallory weiß: In Matrix gibt es einen wichtigen Unterschied zwischen Benutzer- und Gerätekennungen. Die Benutzerkennung wird auf dem Smartphone generiert. Die Gerätekennung dagegen wird vom Matrix-Server vergeben, wenn sich das Gerät zum ersten Mal verbindet. Mallory, die den Matrix-Server kontrolliert, kann also die Gerätekennung manipulieren. Dies nutzt sie folgendermaßen aus: Als Alice sich erstmals als Benutzer am Matrix-Server registriert, erstellt Mallory heimlich ein zweites Benutzerkonto, eine gefälschte (engl. „fake“) Alice. Die echte Alice erhält eine Benutzerkennung, auf die Mallory keinen Einfluss hat. Die Gerätekennung von Alice‘ Smartphone dagegen manipuliert Mallory so, dass sie mit der Benutzerkennung von Fake-Alice identisch ist.

Gerätekennung von Alice = Benutzerkennung von Fake-Alice.

Dass eine Gerätekennung und eine Benutzerkennung den gleichen Wert haben, ist ein Zustand, den die Programmierer nicht berücksichtigt haben. Und das hat schwerwiegende Konsequenzen.

Der ultimative Hack

Mallory muss nur noch abwarten, wie das Übel seinen Lauf nimmt. Alice und Bob führen nichts ahnend den Out-of-Band-Prozess durch, woraufhin Alice‘ Smartphone die Key Message an Bobs Smartphone sendet. Der Inhalt sieht (sinngemäß und stark vereinfacht!) wiefolgt aus:

KEY MESSAGE

OUT-OF-BAND-CODE = Zwischen Alice und Bob telefonisch ausgetauschtes Codewort

BITTE UM SIGNATUR FOLGENDER KENNUNGEN:

KENNUNG 1 = Gerätekennung von Alice (= Benutzerkennung von Fake-Alice)

KENNUNG 2 = Benutzerkennung von Alice

Auf Bobs Smartphone beginnt VERIFY mit der Arbeit. Es prüft zunächst den Out-of-Band-Code. Dieser ist völlig in Ordnung. Die Nachricht kommt ja wirklich von Alice. Als nächstes sieht VERIFY die „Kennung 1“. VERIFY weiß noch nicht, ob es sich hierbei um eine Geräte- oder eine Benutzerkennung handelt. Es sucht daher zuerst nach einem Gerät mit der gegebenen Kennung. Und natürlich gibt es solch ein Gerät, nämlich Alice‘ Smartphone. VERIFY prüft anschließend nicht mehr, ob es sich bei Kennung 1 eventuell auch um eine Benutzerkennung handelt. Es hält das für unnötig, denn vorgesehen ist ja nur „entweder-oder“.

VERIFY glaubt nun, dass eine Gerätekennung signiert werden soll und übergibt Kennung 1 zu diesem Zweck an SIGN. SIGN wiederum weiß zu Beginn ebenfalls nicht, ob es sich um eine Geräte oder eine Benutzerkennung handelt. Das Fatale: SIGN geht umgekehrt vor und sucht zunächst nach einem passenden Benutzer mit dieser Kennung. Und damit wird es auch fündig, es findet Fake-Alice. Daraufhin führt SIGN in Bobs Namen die Signatur mit dem falschen Benutzer durch und Mallory hat gewonnen. Bobs Smartphone wird nun Fake-Alice vertrauen und fortan für die echte Alice halten. Das gleiche Verwirrspiel betreibt Mallory umgekehrt mit einem Fake-Bob, den Alice für den echten Bob hält. Die Man-in-the-Middle-Position (oder Mallory-in-the-Middle) ist somit eingenommen. Mallory kann alle Nachrichten zwischen Alice und Bob mitlesen.

Kleiner Fehler, große Schwachstelle

Es ist ein unscheinbarer Fehler im Programm, der hier ausgenutzt wird. Würden VERIFY und SIGN die Prüfung auf Geräte- oder Benutzerkennung in der selben Reihenfolge durchführen, gäbe es kein Problem. Jedes Unterprogramm für sich allein genommen macht auch alles richtig. Erst in der Kombination ergibt sich eine Schwachstelle. Hier hätten die Entwickler ein einheitlichen Vorgehen wählen müssen. Aber auch eine bessere Trennung zwischen Geräte- und Benutzerkennungen hätte den Angriff von vorneherein verhindert. Dafür würde es schon reichen, wenn Gerätekennungen mit „G“ und Benutzerkennungen mit „B“ begännen. Dann wäre die Doppelverwendung ausgeschlossen. Aber hinterher ist man eben immer schlauer.

Ich denke, es wird ersichtlich, dass man eine ganze Menge Aufwand betreiben muss, um solche Schwachstellen zu entdecken. In Filmen benötigen die Hacker immer nur Sekunden um überall hineinzugelangen. Das ist nicht die Realität, es steckt tatsächlich Arbeit dahinter, viel Fleiß und Kreativität. Den Aufwand betreiben die „Guten“ wie die „Bösen“ gleichermaßen. Der Unterschied ist lediglich, wie man nach dem Auffinden einer Sicherheitslücke mit der Information umgeht. Die Analystengruppe, die den Angriffspunkt in Matrix entdeckte, meldete es zuerst den Entwicklern. Somit hatten diese die Chance, das Problem zu beheben bevor die Arbeit veröffentlicht wurde. Doch man weiß ja nicht, ob es nicht schon vor geraumer Zeit einem bösartigeren Hacker aufgefallen ist, der dies die ganze Zeit ausgenutzt hat. Im Falle des Bundeswehr-Messengers könnte man sicher auch eine schöne Verschwörungstheorie stricken, aber das überlasse ich anderen. Gehen wir mal davon aus, dass man dort genauso unwissend war wie sonst überall. In diesem Sinne, bleibt wachsam!