Dies war eine wilde Fahrt, die viele wertvolle Erkenntnisse lieferte. Kurz gesagt: TeamViewer speicherte Benutzerpasswörter, verschlüsselt mit AES-128-CBC, unter Verwendung eines fest kodierten Schlüssels (0602000000a400005253413100040000) und Initialisierungsvektors (IV) (0100010067244F436E6762F25EA8D704) in der Windows-Registrierung. Wenn das Passwort an anderer Stelle wiederverwendet wird, ist eine Privilegieneskalation möglich. Selbst ohne RDP-Rechte auf einem System kann TeamViewer für den Fernzugriff genutzt werden. Darüber hinaus ermöglicht TeamViewer das Kopieren von Daten oder die Planung von Aufgaben, die über den als NT AUTHORITYSYSTEM ausgeführten Dienst ausgeführt werden, sodass ein Benutzer mit geringen Rechten mithilfe einer .bat-Datei sofort Systemrechte erlangen kann. Diese Schwachstelle wurde unter CVE-2019-18988 registriert.
Der Beginn einer Entdeckungsreise
Alles begann bei einem Kunden vor Ort, dessen Sicherheitsteam hervorragende Arbeit geleistet hatte. Sie hatten alle Punkte des letztjährigen Berichts behoben. Unkenntnis über mimt6 ermöglichte es uns jedoch, einige Hashes zu erhalten. Nach dem erfolgreichen Knacken eines Hashes stellten wir fest, dass das System extrem gut abgesichert war. Selbst der Netzwerkadministrator hatte keine lokalen Administratorrechte auf Windows-Maschinen und auch keine RDP-Rechte. Wir konnten einige offene Freigaben finden und uns mit ihnen verbinden. Dabei stießen wir auf ein Backup von TeamViewer-Registrierungsschlüsseln. Mir fiel auf, dass Begriffe wie OptionsPasswordAES oder SecurityPasswordAES auftauchten. Eine kurze Recherche ergab, dass diese Schlüssel nicht direkt verwertbar waren. Es war jedoch möglich, die Registrierungseinstellungen zu importieren oder über eine .msi-Datei bereitzustellen, um alle TeamViewer-Installationen in der Organisation mit demselben Passwort zu konfigurieren. Dies führte zu der Annahme, dass ein gemeinsamer Schlüssel für alle TeamViewer-Installationen verwendet wurde, was durch die Erwähnung von AES in den Registrierungsschlüsseln untermauert wurde. Obwohl wir den Kunden damals nicht rechtzeitig kompromittieren konnten, blieben die TeamViewer-Registrierungsschlüssel in meinem Gedächtnis und initiierten diese intensive Untersuchung.
Die Suche nach dem Schlüssel: Reverse Engineering und Herausforderungen
Der erste Schritt war die Beschaffung des exakten TeamViewer-Installers der Version 7, deren Registrierungsschlüssel im Backup gefunden wurden. TeamViewer bietet dankenswerterweise weiterhin alle alten Versionen zum Download an. Ich richtete eine neue Windows 10 VM ein und installierte TeamViewer 7. Nach etwas Experimentieren mit den Einstellungen importierte ich die Registrierungsschlüssel und wurde umgehend aus dem Menü für die Optionsänderungen ausgeschlossen. Der Schlüssel OptionsPasswordAES dient dazu, unbefugte Personen vom Ändern der Einstellungen abzuhalten. Da ich das Passwort nicht kannte, versuchte ich spontan, BulletPassView von NirSoft auszuführen. Überraschenderweise zeigte es mir ein Passwort im Klartext an. Exzellent, nun konnte ich wieder auf die Optionsseite zugreifen und den Sicherheitsbereich des Menüs überprüfen. Ich hoffte, das vordefinierte Passwort für den unbeaufsichtigten Zugriff würde ebenfalls in BulletPassView erscheinen. Es wurde jedoch nur als Sternchen angezeigt.
Auf dem Rückflug vom Kunden sah ich LiveOverflows Video über Windows Game Hacking und wie man mit Cheat Engine den Speicher durchsuchen kann. Also lud ich Cheat Engine auf die VM herunter und suchte nach dem zuvor gefundenen Passwort. Es gab einen Treffer! Ich durchsuchte diese Speicherregion und entdeckte, dass das Options-Passwort im Klartext im Speicher zwischen den Bytes 080088 und 000000000000 gespeichert ist. Weiterhin fand ich zwischen 090088 und 000000000000 die beiden unterschiedlichen Passwörter, die ich suchte! Es stellte sich heraus, dass diese Klartext-Zugangsdaten im Speicher bereits gefunden und unter CVE-2018-14333 registriert worden waren. Es gab sogar einen Bericht über APT41, der beschrieb, wie sie TeamViewer-Benutzer angriffen oder TeamViewer für den Fernzugriff nutzten. Die Tweets wurden zwar gelöscht, sind aber hier noch einsehbar.
Die Jagd nach dem AES-Schlüssel
Nachdem ich mit einigen Kollegen über die Suche nach dem Schlüssel zur Entschlüsselung zukünftiger Kundenpasswörter gesprochen hatte, fragte @knavesec, ob meine VM mit dem Internet verbunden sei. Ich bejahte und stellte dann fest, dass ich testen musste, ob die VM den AES-Schlüssel herunterlädt oder ob dieser in der Binärdatei selbst gespeichert ist. Ich richtete eine neue Windows 10 VM ein, stellte das Netzwerk in den Host-Only-Modus und kopierte den TeamViewer-Installer über einen auf meinem Host-Computer laufenden HTTP-Server. Ich konnte die Passwörter tatsächlich immer noch im Klartext sehen.
Nun musste ich IDA Pro starten und die riesige TeamViewer-Binärdatei reverse engineeren. Ich verbrachte Wochen mit diesem Teil. Es erreichte einen Punkt, an dem ich voraussagen konnte, ob IDA abstürzen würde, basierend darauf, ob es X-Refs zu einem bestimmten String in der Binärdatei erkannte. Ich speicherte Speicherinhalte an zufälligen Stellen und durchlief jeden 32-Byte-Block des Speichers, um herauszufinden, ob ich den Schlüssel durch Zufall finden konnte. Dies gelang mir nicht, und ich schrieb es der Verwendung von Python für die AES-Entschlüsselung zu, und bemerkte, dass der String Rijndael in TeamViewer vorkam, also verwendeten sie möglicherweise echtes Rijndael und nicht AES.
Ich fand heraus, dass TeamViewer Crypto++ für seine Ver- und Entschlüsselung verwendete. Es stellte sich heraus, dass einer der unterstützten Modi in libcrypto++ Rijndael war. Ich dachte, ich wäre endlich auf etwas gestoßen. Ich verwendete API Monitor, um TeamViewer Schritt für Schritt zu durchlaufen, und Cheat Engine, um nach den Passwörtern zu suchen. Sobald sie im Speicher auftauchten, dumpte ich den Prozessspeicher mit Procdump und durchlief dann jeden einzelnen 32-Byte-Speicherblock als Schlüssel, Byte für Byte verschiebend, um jede mögliche Kombination zu erfassen. Da ich dies nun in C++ statt in Python tat, ging es ziemlich schnell. Es lieferte jedoch nichts (Spoiler: vielleicht doch, aber ich suchte nach dem Falschen). Ich dachte, Procdump würde möglicherweise etwas komprimieren, also lernte ich, wie man Speicher mit Frida dumpte, und durchlief auch dort jede Möglichkeit, erneut ohne Erfolg. Ich beschloss, zum Reverse Engineering der Binärdatei zurückzukehren. Um die Kompatibilität und Funktionen von verschiedenen Softwarelösungen zu verstehen, ist es oft hilfreich, ähnliche Ansätze zu prüfen, wie bei der Analyse von MS Teams in Firefox.
Der Durchbruch mit einem Debugger
Ich verbrachte so viel Zeit damit, die Binärdatei zu durchsuchen, dass ich wusste, es musste einen besseren Weg geben. Ich recherchierte weiter und stellte fest, dass viele Leute die AES-Schlüssel für Assets in Unity-Spielen finden wollten. Dies führte mich zu einem Blogbeitrag, wo mir klar wurde, dass ich zu kompliziert dachte und einfach einen Debugger verwenden musste. Nach etwa sechs Stunden Einzelschritt-Debugging durch TeamViewer, weil ich nichts verpassen wollte, landete ich im Codebereich, der für die AES-Entschlüsselung verantwortlich war. Hier ein Auszug aus meinen Notizen: