TeamViewer: Ein Konzept macht noch keine Sicherheit

01.07.2014 yahe legacy security thoughts

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 mit den "Teamviewer Sicherheitsinformationen". 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 Technologien einsetzt, die so ähnlich bereits anderswo erfolgreich eingesetzt werden. Ein Statement interessiert mich dabei besonders:

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 Client A und Client B generiert und der Public Key des Clients an Server S übertragen. Die Schlüssel werden für die Übertragung mit dem öffentlichen Masterschlüssel von Server S 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

Kommen wir also zum eigentlichen Verbindungsaufbau zwischen zwei Clients. Die 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 von Server S den Public Key von Client B. Die Anfrage ist mit dem öffentlichen Masterschlüssel von Server S verschlüsselt. Der Public Key von Client B wird vom Server S an Client A geschickt, verschlüsselt mit dem Public Key von Client A und signiert mit dem Masterschlüssel von Server S. Beide Daten sind TeamViewer natürlich bekannt. Nun erzeugt Client A einen symmetrischen AES-256-Schlüssel, verschlüsselt ihn mit dem Public Key von Client B, den er von Server S erhalten hat und signiert ihn mit seinem eigenen Private Key. Dieses Paket X wird nun an Server S geschickt, damit dieser es an den Client B weiterleitet. Nach dem Erhalt fragt Client B den Public Key von Client A bei Server S an. Die Anfrage ist wiederum mit dem öffentlichen Masterschlüssel von Server S verschlüsselt. Server S 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 von 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

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 etwa doch? 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 dessen öffentlichen Schlüssel erfragen. Der zentrale Server S 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 Server S den symmetrischen AES-256 Schlüssel mit dem passenden privaten Fake-Schlüssel für Client B, verschlüsselt den symmetrischen AES-256 Schlüssel mit dem tatsächlichen öffentlichen Schlüssel von Client B, 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 Client B den Public Key von Client A bei Server S an. Dieser antwortet jedoch stattdessen mit dem öffentlichen Fake-Schlüssel für Client A. Die Signatur des Paket Y passt mit dem erhaltenen ö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

Praktischerweise bestimmt nun auch noch TeamViewer, ob eine direkte TCP-/UDP-Verbindung aufgebaut wird oder ob die Routingserver von TeamViewer verwendet werden. Dank des unsicheren Schlüsselaustauschs können die Routingserver den symmetrischen AES-256-Schlüssel verwenden, um den gesamten Traffic zwischen Client A und Client B zu entschlüsseln. Die Aussage aus dem Dokument, dass dieses Mitlesen nicht möglich sei, ist also schlichtweg falsch.

Ob es Absicht ist, dass TeamViewer sämtliche Datenverbindungen mitlesen kann? Ich weiß es nicht. 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 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.


Search

Categories

administration (45)
arduino (12)
calcpw (3)
code (38)
hardware (20)
java (2)
legacy (113)
linux (31)
publicity (8)
raspberry (3)
review (2)
security (65)
thoughts (22)
update (11)
windows (17)
wordpress (19)