Dieses Repository enthält den Exploit-Proof-of-Concept einer Schwachstelle in TeamViewer, die es einem unprivilegierten Benutzer ermöglicht, einen beliebigen Kernel-Treiber in das System zu laden. Ich möchte der Zero Day Initiative für die Koordination mit ihnen bei der Meldung und verantwortungsvollen Offenlegung der Sicherheitslücke danken.
Die Details zu der Forschung, die mit diesen Schwachstellen endete, finden Sie in der folgenden dreiteiligen Blogserie auf meinem Blog. Sie behandeln diese Schwachstellen ausführlicher und zeigen auch, wo ich während des Prozesses versagt habe. Teil drei macht Spaß :P.
Videos des Exploits finden Sie hier:
Nachdem es möglich war, beim Herstellen einer Verbindung zum SYSTEM-Dienst IPC einen gültigen TeamViewer-Client zu fälschen (nur eine einfache Authentifizierung, wie im Blog beschrieben), war es möglich, eine willkürliche Treiberinstallation auszulösen. TeamViewer hat die Signatur des zu installierenden Treibers nicht überprüft.
Somit war dank TeamViewer eine Privilegienskalierung von USER auf KERNEL möglich.
Einer der besten Ansätze besteht darin, die bekannte Technik BYOD (Bring Your Own Vulnerable Driver) zu verwenden, um einen gültigen signierten Treiber in den Windows-Kernel zu laden und ihn dann auszunutzen, um privilegierte Aktionen auf Benutzerebene auszuführen, wie etwa das Ändern des Tokens eines beliebigen Treibers Prozess mit einem Privilegierten.
Wenn TeamViewer auf dem System installiert wird, erstellt es einen Dienst, der als SYSTEM ausgeführt wird: TeamViewer_service.exe
Dieser Dienst unterstützt den Kunden bei einigen Aufgaben. Daher wird der Client nicht mit erhöhten Rechten ausgeführt und einige Aufgaben werden an den Dienst delegiert.
Die Kommunikation mit dem Dienst (IPC) wird über Sockets implementiert (unter Verwendung von Overlapped I/O und IoCompletionPort ). Standardmäßig lauschen die TeamViewer SYSTEM-Dienste auf 5939/tcp bei localhost.
TeamViewer filtert nicht die vom Client gesendeten Parameter, um nach der Treiberinstallation, Signaturprüfung usw. zu fragen.
Die Idee ist also: Wir werden einen TV-Client fälschen und nach der Installation eines VPN-Treibers fragen, aber eine andere INF angeben. Ich habe die gleiche ursprüngliche INF-Datei von TeamViewer wiederverwendet, aber in einem anderen (nicht privilegierten) Pfad, indem ich den „schlechten“ Treiber in teamviewervpn.sys umbenannt habe, da dies der Treibername ist, auf den die ursprüngliche INF abzielt.
Dadurch wird auch die TeamViewer-Option umgangen. Änderungen erfordern Administratorrechte auf diesem Computer .
Diese Prüfung ist nur über die GUI wirksam, da die TeamViewer-Optionen beim Klicken auf die Schaltfläche mit einem nicht privilegierten Benutzer deaktiviert sind. Es ist jedoch möglich, eine Verbindung zum Socket herzustellen und einen beliebigen Treiber zu laden.
Der Exploit ist aufgrund der IPC-Nachricht, in der der Client seine PID und andere Daten in der Version angibt, von der Version abhängig. Die Version des Clients muss mit der Version des SYSTEM-Dienstes übereinstimmen. Der Exploit muss in Main.cpp auf die Zielversion von TeamViewer_service.exe geändert werden (Zeilen 140 bis 143).
Im Grunde fälschen wir also einen TeamViewer-Client, der eine Verbindung zum SYSTEM-Dienst herstellt, und fordern die Installation eines beliebigen Treibers an. Der TeamViewer-Dienst lädt es bitte in den Kernel.
TeamViewer hat eine weitere IPC-Meldung, die der ersten sehr ähnlich ist, die ich zuerst entdeckt habe (wird beim Klicken auf „VPN-Treiber installieren“ angezeigt). Diese andere Meldung dient der Installation des Druckertreibers .
Im Wesentlichen sind CVE-2024-7479 und CVE-2024-7481 gleich, aber TeamViewer hat zweimal denselben Fehler begangen. Die Botschaften sind zwar unterschiedlich, aber sehr ähnlich. Sie haben unterschiedliche IPC- Methoden-IDs .
Das Ergebnis ist dasselbe, es kann ein beliebiger Treiber geladen werden.
