TeamViewer: Ein Konzept macht noch keine Sicherheit

Heute hatte ich das Vergnügen, die Bekanntschaft mit dem TeamViewer zu machen - einem Tool, das es ermöglicht, VPN-Verbindungen durch restriktive Firewalls hindurch aufzubauen. Das ganze funktioniert mit einer User-ID und einem Passwort, was gerade dazu einlädt, diese einfache Lösung zu verwenden. Aber wie genau funktioniert das dann? Und wie sicher ist der Verbindungsaufbau und die darüber übertragenen Daten?

Einen ersten Anhaltspunkt gibt die Menge der Konfiguration - annähernd null, ziemlich wenig für eine typische VPN-Verbindung. Die Verwendung einer User-ID lässt den Schluss zu, dass ein zentraler Server beim Verbindungsaufbau involviert ist. Weiteren Aufschluss über die Vorgänge beim Verbindungsaufbau gibt das Dokument, das die "Teamviewer Sicherheitsinformationen" enthält.

Dort wird lang und breit erklärt, wie viele Zertifizierungen man hat, dass man tollen ISO-Standards entspricht, europäische Server verwendet, viel Wert auf den Schutz personenbezogener Daten legt und Technologie einsetzt, die - so ähnlich - bereits anderswo erfolgreich eingesetzt werden. Ein Statement interessiert mich dabei besonders, nämlich:

Wie später im Abschnitt „Verschlüsselung und Authentifizierung“ beschrieben, können auch wir als Betreiber der Routingserver den verschlüsselten Datenverkehr nicht einsehen.

Allerdings stellt sich die Frage, ob das wirklich so ist. Sehen wir uns im ersten Schritt die Registrierung der Schlüssel an. Diese werden von den jeweiligen Clients "A" und "B" generiert und der Public Key jeweils und an den Server "S" übertragen. Die Schlüssel werden mit dem öffentlichen Masterschlüssel des Servers verschlüsselt. Da jedoch Server und Masterschlüssel unter der Kontrolle von TeamViewer sind, stellt das kein Hindernis dar. Eine weitere Validierung findet laut dem Dokument nicht statt.

TeamViewer: Key Ceremony

TeamViewer: Key Ceremony

Kommen wir also zum eigentlichen Verbindungsaufbau zwischen zwei Clients. Die jeweilige Authentisierung der Clients via SRP lasse ich an dieser Stelle außen vor, da diese nur zwischen einem Client und dem Server stattfindet, aber nicht unter den Clients.

Als erstes erfragt Client A vom Server den Public Key von Client B - die Anfrage ist mit dem öffentlichen Masterschlüssel des Servers verschlüsselt. Der Public Key von Client B wird vom Server an Client A geschickt - verschlüsselt mit dem Public Key von Client A und signiert mit dem Masterschlüssel des Servers. Beide Daten sind TeamViewer natürlich bekannt.
Nun erzeugt Client A einen symmetrischen AES-256 Schlüssel, verschlüsselt ihn mit dem vom Server erhaltenen Public Key von Client B und signiert ihn mit seinem eigenen Private Key. Dieses Paket X wird nun an den Server geschickt, damit dieser es an den Client B weiterleitet.
Nach dem Erhalt fragt der Client B den Public Key von Client A beim Server an - die Anfrage ist wiederum mit dem öffentlichen Masterschlüssel des Servers verschlüsselt. Der Server antwortet mit dem Public Key von Client A, den er mit dem öffentlichen Schlüssel von Client B vor der Übertragung verschlüsselt und mit seinem eigenen Masterschlüssel signiert.
Nun prüft Client B die Signatur des Paket X mit dem erhaltenen Public Key von Client A und kann anschließend den symmetrischen AES-256 Schlüssel mit seinem eigenen Private Key entschlüsseln.

TeamViewer: Connection Establishment

TeamViewer: Connection Establishment

Damit haben nun Client A und Client B einen gemeinsamen, symmetrischen AES-256 Schlüssel und können diesen verwenden, um verschlüsselt untereinander zu kommunizieren. Da TeamViewer die privaten Schlüssel der Clients nicht kennt, können sie auch nicht den ausgetauschten symmetrischen Schlüssel in Erfahrung bringen...

...oder?

Hier schlägt nun nämlich ein großes Problem zu: der zentrale Server. Die Clients müssen diesem blind vertrauen. Während des Schlüsselaustauschs ist er jedoch in solcher einer Machtposition, dass überhaupt nicht ersichtlich ist, ob er tatsächlich keinen Zugriff auf den symmetrischen AES-256 Schlüssel hat.

Nehmen wir uns mal folgendes Szenario: Der Client A möchte gern eine Verbindung zu Client B aufbauen und muss dazu den öffentlichen Schlüssel von Client B erfragen. Der zentrale Server könnte nun mit einem öffentlichen Fake-Schlüssel für Client B antworten, zu dem der Server auch den passenden privaten Fake-Schlüssel kennt.
Der Client A würde nun mit diesem öffentlichen Fake-Schlüssel den symmetrischen AES-256 Schlüssel verschlüsseln und mit seinem privaten Schlüssel signieren. Dieses Paket X würde der Client A nun an den Server schicken, damit dieser es an Client B weiterleitet.
Anstatt es jedoch einfach weiterzuleiten, entschlüsselt der Server den symmetrischen AES-256 Schlüssel mit dem passenden privaten Fake-Schlüssel, verschlüsselt den symmetrischen AES-256 Schlüssel mit dem tatsächlichen öffentlichen Schlüssel von Client B und signiert das ganze mit einem privaten Fake-Schlüssel für Client A und schickt dieses neue Paket Y erst dann an Client B weiter.
Nach dem Erhalt fragt der Client B den Public Key von Client A beim Server an - dieser antwortet jedoch stattdessen mit dem öffentlichen Fake-Schlüssel für Client A.
Die Signatur des Paket Y passt mit dem öffentlichen Fake-Schlüssel überein, der symmetrische AES-256 Schlüssel ist mit dem korrekten öffentlichen Schlüssel von Client B verschlüsselt, also muss das erhaltene Paket Y ja valide sein und der enthaltene Schlüssel kann verwendet werden.

TeamViewer: Possible MITM Attack

TeamViewer: Possible MITM Attack

Praktischerweise bestimmt nun auch noch TeamViewer, ob eine direkte TCP-/UDP-Verbindung aufgebaut wird oder ob die Routingserver von TeamViewer verwendet werden. Dank des schwachen Schlüsselaustauschs kann den Routingservern der notwendige symmetrische AES-256 Schlüssel gegeben werden, die nun in der Lage sind, den gesamten Traffic zu entschlüsseln. Die Aussage aus dem Dokument, dass dieses Mitlesen nicht möglich wäre, ist also schlichtweg falsch.

Ob es Absicht ist, dass TeamViewer sämtliche Datenverbindungen mitlesen kann? Ich weiß es nicht genau. Es ist jedoch auffällig, dass sie bei der Authentisierung zwischen Client und Server ein relativ komplexes, Diffie-Hellmann-ähnliches Verfahren einsetzen, während sie beim Austausch des symmetrischen Schlüssels nicht auf ein Verfahren setzen, das aus einem gemeinsamen Geheimnis - zum Beispiel ausgetauscht über einen zweiten Kanal - einen sicheren Sitzungsschlüssel erzeugt.

Die Entscheidung, ob man einer zentralen Instanz Zugriff auf sämtliche übertragenen Daten geben möchte, sollte an dieser Stelle jeder für sich selbst treffen.

MITM-Grüße, Kenny

1 Kommentar » Schreibe einen Kommentar

  1. Hi!

    Sehr interessant, meine Überlegungen ist in die selbe RICHTUNG gegangen.
    Ich setzte TeamViewer nicht ein, es gibt genug Alternative bei welchen ich auf einen Routingserver nicht angewiesen bin.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.