Operationalisierung von Browser-Ausnutzung, um die Anwendung Windows Defender Application Control (WDAC) zu umgehen
Windows Defender Anwendung Control (WDAC) ist eine Windows-Sicherheitsfunktion , die dazu beitragen soll, dass nicht autorisierter Code (wie Malware oder nicht vertrauenswürdige ausführbare Dateien und Skripte) auf einem System nicht ausgeführt wird. Es handelt sich dabei um einen Mechanismus für das Whitelisting von Anwendungen, der Richtlinien durchsetzt, die nur ausdrücklich vertrauenswürdige ausführbare Dateien, Skripte und Treiber auf einem System zulassen. Es wird häufig in Hochsicherheits- oder streng kontrollierten Umgebungen eingesetzt, in denen Sicherheit und Systemintegrität kritisch sind, wie etwa in denen, die das X-Force Red Adversary Simulation Team testet.
Vor einigen Wochen veröffentlichte mein Kollege Bobby Cooke einen Blogbeitrag , in dem er eine Methode beschreibt, selbst die strengsten WDAC-Richtlinien zu umgehen, indem man vertrauenswürdige Electron-Anwendungen hinter die Tür schiebt. Ich kann seinen Blogbeitrag nur empfehlen, um ihn zu lesen, um sich ein Bild davon zu machen, wie Electron-Anwendungen Node.js verwenden und wie sie durch Backdoors ersetzt werden können.
Im Rahmen dieser Forschung hat er auch Loki C2, ein Node.js-basiertes Modell, als Open-Source veröffentlicht Command-and-Control-Framework. Dank der hervorragenden Arbeit von Bobby und Dylan Tran bei der Entwicklung von Loki C2 ist es dem X-Force Adversary Simulation Team gelungen, Code-Ausführung bei Gefechten in gehärteten Umgebungen mit WDAC zu erreichen.
Und wo kommt diese Forschung ins Spiel? Die zuvor genannte Technik hat jedoch einen Nachteil: Sie ist auf die Ausführung von JavaScript-Code beschränkt und kann keinen nativen Code ausführen, wie z. B. DLLs laden oder EXEs ausführen. Sie können auch keinen Shellcode ausführen, um eine C2-Nutzlast der Stufe 2 zu starten. Dieser Blogbeitrag beschreibt eine Technik, mit der wir diese Einschränkungen umgehen konnten.
Zunächst begannen Bobby und ich mit dem Reverse Engineering signierter Node.js-Module, die von Electron-Anwendungen geladen wurden, um nach Schwachstellen zu suchen, die eine Ausführung von Code auf niedriger Ebene, auf Befehlsebene, ermöglichen könnten. Nach einiger anfänglicher Erkundung und auf Vorschlag von jeffssh richtete sich meine Aufmerksamkeit auf den V8-Motor, der von Node.js und von Chrome verwendet wird.
Anstatt eine Schwachstelle in einem Node.js-Modul zu finden, können Sie doch einfach die V8-Engine mit einem N-Day ausnutzen?
Das Angriffsszenario ist bekannt: Sie bringen eine verwundbare, aber vertrauenswürdige Binärdatei mit und missbrauchen die Tatsache, dass sie vertrauenswürdig ist, um in das System einzudringen. In diesem Fall verwenden wir eine vertrauenswürdige Electron-Anwendung mit einer verwundbaren Version von V8, ersetzen main.js durch einen V8-Exploit, der Stufe 2 als Payload ausführt, und voilà, wir haben eine native Shellcode-Ausführung. Wenn die ausgenutzte Anwendung von einer vertrauenswürdigen Stelle (wie z. B. Microsoft) auf die Whitelist gesetzt/signiert wurde und normalerweise gemäß der verwendeten WDAC-Richtlinie ausgeführt werden dürfte, kann sie als Vehikel für die schädliche Nutzlast verwendet werden.
Neben der Möglichkeit, Shellcode frei auszuführen, hat dieser Ansatz auch den Vorteil, dass der Shellcode im Kontext eines browserähnlichen Prozesses ausgeführt wird, was Vorteile hat. Verhalten, das von EDR sonst als verdächtig eingestuft werden könnte, erscheint für einen Browser normal, wie beispielsweise die Verwendung von RWX-Speicher für Just-In-Time (JIT)-Code.
Verstärken Sie Ihre Sicherheitsintelligenz
Bleiben Sie Bedrohungen immer einen Schritt voraus mit Neuigkeiten und Erkenntnissen zu Sicherheit, KI und mehr, die Sie wöchentlich im Think Newsletter erhalten.
Dieser Ansatz schien recht unkompliziert, aber ich hatte noch einige offene Fragen. Würde ein öffentliches Chrome V8 N-Day-Exploit wirklich innerhalb einer Electron-App funktionieren? Wie unterscheidet sich die in Chrome verwendete V8-Engine von der in Node.js? Welche Änderungen sind für das Ausnutzen erforderlich? Wie kann ich diesen Fehler beheben?
Es stellt sich heraus, dass es bereits öffentliche Arbeiten zur Ausbeutung von V8-Exploits in Electron-Apps gibt, die ich leider erst nach dem Abschluss gefunden habe. Turb0 deckt hervorragend den (etwas quälenden) Prozess ab, einen öffentlichen v8-Exploit und die zugehörigen Lese-/Schreib-Primitive so anzupassen, dass sie in einer Electron-Anwendung funktionieren. Der Blogbeitrag von Turb0 deckt bereits viele der technischen Details ab, mit denen ich zu kämpfen hatte, und ich empfehle Ihnen dringend, sich das anzusehen. Der Rest dieses Blogbeitrags konzentriert sich auf die verbleibenden Phasen des Exploit-Entwicklungszyklus im Zusammenhang mit der gezielten Zielsetzung von Windows mit dem spezifischen Ziel, eine WDAC-Umgehung zu erstellen, sowie auf Probleme, die ich bei der Operationalisierung des Exploits für den realen Einsatz festgestellt habe.
Als Erstes musste ich die genauen Ziele herausfinden. Ich musste eine vertrauenswürdige Electron-Anwendung auswählen und eine Sicherheitslücke finden, um sie auszunutzen. Ich hatte zuvor nur sehr wenig Erfahrung mit Browser-Ausbeutung, daher sollte die gewählte Schwachstelle einen öffentlich verfügbaren Ausnutzen haben, der als Ausgangspunkt dienen kann.
Ich war mir nicht sicher, wie die V8-Versionen der von Electron verwendeten V8-Version zugeordnet sind oder wie man feststellen kann, ob es tatsächlich anfällig ist. Die Electron-Version von V8 hinkt oft der neuesten Version von Chromes V8 hinterher. Die Entwickler von Electron portieren wichtige Sicherheitspatches aus neueren Versionen in die Version, die sie für eine bestimmte Electron-Version eingefroren haben. Das heißt, selbst wenn Electron eine ältere Version von V8 verwendet, bedeutet das nicht unbedingt, dass es anfällig für einen Fehler ist, da ein Fix hätte zurückportiert werden können. Die von ihnen ausgewählten Patches werden hiergespeichert.
Ich entschied, dass es am einfachsten wäre, eine Sicherheitslücke auszunutzen, die nach der Veröffentlichung der Anwendung gepatcht wurde. Auf diese Weise bestünde absolut keine Möglichkeit, dass diese Version der App bereits gepatcht worden wäre. Nach einiger Recherche habe ich Downloads für die letzten ~2 Jahre von VSCode-Veröffentlichungen gefunden. Ich hatte eine ordentliche Auswahl an anfälligen, von Microsoft signierten Anwendungen zur Auswahl unter 😊.
Zunächst habe ich einfach einen kürzlich veröffentlichten V8-Exploit-PoC genommen, die anfällige Electron-App damit durch die Hintertür zugänglich gemacht, main.js durch den Exploit ersetzt und die Daumen gedrückt. Vielleicht wäre es ja wirklich so einfach, nicht wahr? Ich hatte zumindest auf einen Absturz gehofft. Wie erwartet, passierte beim Starten der App nichts. Widerwillig wusste ich, dass ich V8 bauen musste, um zu verstehen, was auf einer tieferen Ebene vor sich ging. Indem ich V8 selbst kompiliere, konnte ich die Debug-Version (d8) erstellen, tief in den Exploit eindringen und ihn dann für die spezifische Version anpassen, die ich anvisiert habe.
Mein erstes Ziel war es, eine „Grundwahrheit“ zu schaffen – die exakte Umgebung nachzubilden, in der das Ausnutzen bekanntermaßen funktioniert. Dann konnte ich die Unterschiede zwischen dieser Version und der Version, die ich anvisierte, untersuchen, um zu verstehen, was falsch lief.
Die meisten der von mir gefundenen öffentlich zugänglichen V8-Ausnutzen zielten auf Linux ab. Also begann ich damit, V8 unter Linux zu kompilieren und den genauen Commit auszuchecken, auf den der von mir gewählte öffentliche Exploit abzielte. Ich habe dann den Exploit ausgeführt, um sicherzustellen, dass er funktioniert. Zum Glück hat es geklappt. Ich hatte nun meine unumstößliche Wahrheit.
Von dort aus kompilierte ich die Version von V8, die ich als Ziel hatte (die gleiche, die auch von der Electron-App verwendet wird), allerdings unter Linux. Der Exploit funktionierte nicht auf Anhieb. Wenn Sie ein Projekt selbst erstellen, haben Sie den Vorteil, dass Sie so viel Einblick in den Code nehmen können, wie Sie möchten. Insbesondere verfügt V8 über d8, die eigenständige Shell für die V8-JavaScript-Engine, die hauptsächlich zum Testen, Debuggen und zum Ausführen von JavaScript- und WebAssembly-Code außerhalb eines Browsers oder einer Node.js-Umgebung verwendet wird. d8 verfügt über interne Debug-Funktionen, aktiviert mit
Damit konnte ich die Adressen der interessanten Objekte ausgeben und die fest codierten Offsets des öffentlichen Exploits anpassen. Jetzt kam ich der Sache näher. Ich musste nur meinen Exploit auf Windows portieren.
Das Kompilieren einer älteren Version von V8 unter Windows hat mir viele Kopfschmerzen bereitet. Ich musste eine Reihe von Problemen mit Abhängigkeiten beheben, daher habe ich einige fragwürdige interne Codeänderungen vorgenommen. Die Details entfallen mir jetzt – mein Gehirn hat sie zu meinem eigenen Schutz ausgeblendet. Nach stundenlangem Kämpfen konnte ich endlich die Version zusammenstellen, die ich brauchte! Zu meiner Überraschung funktionierte der modifizierte Linux-Ausnutzen unter Windows ohne Anpassungen.
Jetzt musste ich nur noch den Exploit in der Electron-App testen und den Atem anhalten ... Ups, hat nicht funktioniert! Aber warum?
Zuerst war ich hoffnungsvoll, weil das Ziel tatsächlich abgestürzt war. Schließlich hatte ich die Linux-Nutzlast nicht für Windows angepasst, also konnte ich nichts Interessantes erwarten. Um das Verhalten zu bestätigen, habe ich den Ausnutzen-Payload so geändert, dass er an Adresse 0x4141414141 ausgeführt wird. Dies ist eine gängige Technik, die Exploit-Autoren verwenden, um zu sehen oder zu beweisen, dass sie die Kontrolle über das Programm erlangt haben, indem sie die Adresse des Instruktionszeigers steuern. Als ich mir den Absturz jedoch in WinDbg ansah, fand ich nicht das, was ich sehen wollte. Beim Überschreiben des Zielfunktionszeigers trat ein Segmentierungsfehler auf.
Erinnert ihr euch an die Sache mit dem Cherry-Picking von V8-Commits durch Electron, von der ich vorhin gesprochen habe? Es stellte sich heraus, dass die App zwar anfällig für den Fehler war, den ich ausnutzen wollte, die Sandbox-Escape-Methode, die der öffentliche Exploit verwendete, jedoch bereits über Cherry-Pick behoben worden war. Falls du mit dem V8-Sandbox/Speicherkäfig nicht vertraut bist, kannst du hier mehr darüber lesen. Im Wesentlichen ist es eine Möglichkeit, die V8-Ausbeutung im Falle einer Sicherheitslücke zu erschweren.
Um zu erkennen, was passiert war, musste ich die Zielversion von V8 erneut erstellen und dieses Mal die ausgewählten Patches anwenden. Zusätzlich zu den Sicherheitspatches wendet Node.js auch spezifische Node.js-Patches auf die von Electron verwendete Version von V8 an. Es hat lange gedauert, bis mir klar wurde, dass ich das überhaupt tun musste, denn wie Electron und Node.js mit ihren verschiedenen Abhängigkeiten umgehen, war nicht sofort klar.
Nachdem ich ein oder zwei Tage lang versucht hatte, sicherzustellen, dass die Version von V8, die ich kompilierte, *identisch* mit meiner Zielversion war, und mich auch über aktuelle Sandbox-Escape-Techniken informiert hatte, kam ich voran. Ich konnte eine Fluchttechnik finden, die für mein Ziel funktionieren würde. Nach Anpassung des Exploits konnte ich die App schließlich mit Kontrolle über den Befehlszeiger zum Absturz bringen. Ein süßer Sieg, ich sah das Ende schon vor mir...
An diesem Punkt blieb nur noch zu tun, die öffentliche Payload zum Ausnutzen so zu modifizieren, dass sie stattdessen unsere C2-Payload ausführt. Diese scheinbar einfache Änderung erwies sich als ärgerlicher als ich gedacht hatte. Die Linux-Nutzlast des öffentlichen Ausnutzens war eine einfache Nutzlast zum Öffnen einer Shell, die nur wenige Bytes groß war. Die Nutzlast der C2 war ... viel größer.
Wer sich mit Shellcode auskennt, weiß, dass das Schreiben von Shellcode unter Windows mühsamer ist als unter Linux, vor allem, weil es keine einfache Möglichkeit gibt, direkte Systemaufrufe positionsunabhängig durchzuführen, wie es unter Linux möglich ist. Die Nutzdaten mussten außerdem in einem Gleitkomma-Array „JOP-geschmuggelt“ werden:
Offensichtlich konnte die gesamte C2-Nutzlast (die mehrere tausend Bytes groß war) auf diese Weise nicht ausgeführt werden. Also musste ich eine Bootstrap-Nutzlast schreiben, die eine ausführbare Seite zuordnet, die endgültige Nutzlast darauf kopiert und dann darauf springt.
Das Problem mit der Bootstrap-Nutzlast ist, dass ich zwar die Programmsteuerung hatte, aber keine Möglichkeit hatte, Argumente an die ausgeführte Nutzlast weiterzugeben. Mein geschmuggelter Shellcode würde also nicht die Adresse der endgültigen Nutzlast kennen, von der aus er kopiert werden soll. Ich umging dieses Problem mit einer Methode, die ich als „Argumentschmuggel“ bezeichnete.
Ich wusste, dass die Adresse des überschriebenen JSFunction-Objekts im rcx-Register gespeichert wird. Mit dem beliebigen Write-Primitiv habe ich die zugeordnete Seite in einem der Felder des Objekts gespeichert, die nicht benötigt wurden. Dies erforderte ein wenig Ausprobieren, da das Überschreiben einiger Offsets zu Abstürzen führte. Ich habe dasselbe für den zu kopierenden Wert und den Offset getan, in den er kopiert werden soll. Der Offset des Feldes könnte fest im Shellcode codiert werden, damit dieser weiß, von wo die Nutzdaten kopiert werden sollen. Ich habe die Nutzlast n-mal aufgerufen, wobei n die Anzahl der zu kopierenden Bytes ist.
TurboFan, der optimierende Compiler von V8, hat meinen Plänen ein paar Strich durch die Rechnung gemacht. Aufgrund der Optimierungen von TurboFan würde das Schmuggeln von Befehlssequenzen, die in mehrere Gleitkommazahlen desselben Werts übersetzt wurden, nur zu einer Instanz dieses Werts im Speicher führen. Dadurch wurde begrenzt, wie oft Anweisungen wiederholt werden konnten. Ich habe dies umgangen, indem ich meinen Shellcode so kompakt wie möglich gestaltet und auch die Position der eingeschleusten Anweisungen variierte, wenn ich eine Anweisung unbedingt wiederholen musste, sodass der Gleitkommawert anders war und es keine wiederholten Einträge gab.
Ich hatte auch Probleme beim Kopieren von Shellcode, wenn die Nutzlast von Stufe 2 zu groß war, wahrscheinlich weil ich die gleiche „stomped“ JSFunction und TurboFan oft aufrufen musste, um das zu optimieren. Ich habe dies schließlich umgangen, indem ich mehrere Schleifen anstelle einer großen Schleife in „WriteShellcode“ kopiert und eingefügt habe. Schrecklich hässlich, aber es hat funktioniert! Später tauschten Bobby und Dylan die C2-Nutzlast gegen einen Stager aus, der die größere Nutzlast aus dem Speicher abrief, so dass die endgültige Nutzlast nicht auf der Festplatte gespeichert werden musste. Dies trug auch dazu bei, die Dateigröße von main.js in einem vernünftigen Rahmen zu halten.
Die Vorbereitung auf den tatsächlichen operativen Einsatz von Exploits sollte stets Tests in verschiedenen Umgebungen beinhalten. Für den Kontext des Einsatzes wussten wir nicht, in welcher Umgebung die Nutzlast ausgeführt werden würde, nur dass es sich um ein Windows-System handelte, das wahrscheinlich WDAC aktiviert hatte. Daher musste der Exploit unabhängig vom Betriebssystem funktionieren. Ich war zuversichtlich, dass da die Version V8 der Anwendung und alle Abhängigkeiten in der App enthalten sind, kaum Variabilität auftreten würde. Mit dieser Annahme lag ich falsch.
Aus Gründen, die ich nicht verstehe, hat sich der Offset des anfälligen Funktionszeigers zum Überschreiben in allen Windows-Versionen geändert. Das war nicht sinnvoll, weil, soweit ich es verstehe, der Offset-Abstand von der V8-JIT-Engine bestimmt wird, deren Bibliotheken direkt aus der Anwendung geladen werden. Das bedeutet, dass unabhängig vom Betriebssystem exakt dieselben V8-Bibliotheken geladen werden. Was die Sache noch verwirrender macht, scheint die Variation keinem bestimmten Muster zu folgen. Bei einigen Windows-Versionen (sowohl älteren als auch neueren) war der Offset manchmal um 4 Bytes falsch. Das war besonders ärgerlich, weil es keine Möglichkeit gab, den richtigen Offset aus dem JavaScript-Exploit herauszufinden (soweit ich das beurteilen konnte). Die einzige Möglichkeit, dies zu berechnen, bestand darin, die Debugging-Shell zu nutzen, um die Speicheradresse zu lesen und die Berechnungen durchzuführen, was innerhalb der Produktions-Electron-Anwendung offensichtlich keine Option war. Kurz gesagt: Die Abweichungen der Offsets können zur Laufzeit des Exploits nicht berechnet werden.
Um das inkonsistente Versatzproblem zu umgehen, haben Bobby und Dylan das Ausnutzen so überarbeitet, dass Main.js das Ausnutzen mehrmals startete und die verschiedenen möglichen Versatzwerte ausprobierte, bis es erfolgreich war. Dies wurde dadurch erreicht, dass der anfängliche Code-Prozess eine Schleife durchführte. Diese Schleife erzeugte Kindprozesse, die den Exploit mit einem eindeutigen Offset versuchten. Wenn das Ausnutzen fehlschlug, würde der untergeordnete Prozess beendet werden. Wenn der Exploit erfolgreich war, führte der Shellcode eine Mutex-Datei aus, bevor die Stufe 2 C2 bereitgestellt wurde. Sobald das ausnutzen erfolgreich war, würde der ursprüngliche Prozess die Schleife verlassen und für immer schlafen.
Das bedeutete zwar, dass ein falscher Verschiebungsversuch einen Absturz verursachen würde, aber unsere Tests zeigten, dass für den Benutzer keine sichtbaren Fehler vorlagen und die Funktionalität der Anwendung weiterhin nahtlos funktionierte. Es war zwar nicht die sauberste Lösung und wegen der Abstürze etwas laut, aber die Zeit war entscheidend. Das nennen wir in der Branche „JIT xdev“, und es hat perfekt für unsere Bedürfnisse funktioniert.
Wir wollten natürlich nicht, dass der Exploit offensichtlich wird, wenn wir erwischt werden und jemand den Einstiegspunkt main.js der Anwendung analysiert. Um das zu vermeiden, haben wir einen JavaScript-Obfuscator auf den Code des Ausnutzens angewendet, der ihn für das menschliche Auge praktisch unverständlich machte. Dank der Talente und des Engagements von Chris Spehn, der die CI/CD-Pipeline für die Payload des Teams betreut, konnten wir die Auslieferung dieser Payload optimieren und den Code bei jeder Generierung neu verbergen, sodass wir die Anwendung unbegrenzt mit unterschiedlichem Ausnutzen-Code wiederverwenden konnten. Dadurch konnte die Nutzlast nicht signiert werden. Das erwies sich als besonders nützlich, da wir leider beim ersten Versuch, die Funktion zu nutzen, erwischt wurden, weil der Benutzer die Phishing-E-Mail 🙁 markiert hatte. Interessanterweise analysierte das blaue Team des Kunden zwar die Anwendung aus der E-Mail, konnte aber weder den Zweck der Anwendung noch das eingebettete V8-Exploit identifizieren.
Ich verstehe immer noch nicht ganz, warum JITted Function Offsets vom Betriebssystem abhängen, da alle relevanten V8-Bibliotheken in der Electron-Anwendung gebündelt sein sollen. Falls jemand eine Ahnung hat, warum das so ist, lassen Sie es mich bitte wissen!
Electron hat eine experimentelle Funktion für die Integrität eingeführt, die die Integrität aller Dateien der Anwendung zur Laufzeit überprüft. Es ist für macOS seit Version 16 und für Windows seit Version 30 verfügbar. Anwendungsentwickler können diese Electron-Sicherung aktivieren, um sicherzustellen, dass keine der Anwendungsdateien manipuliert wird. Wenn dies der Fall ist, wird der Prozess automatisch beendet und nichts wird ausgeführt.
Diese Funktion verhindert die Modifizierung jeglicher im Electron-App-Paket enthaltenen Dateien, einschließlich main.js, und vereitelt die besprochenen Techniken. Allerdings ist es in den gängigsten Anwendungen noch nicht implementiert. Sollte diese Funktion eine größere Verbreitung finden, sollte dennoch beachtet werden, dass ältere Versionen der Anwendung, die vor der Integritätssicherung verwendet wird, für diesen Angriff anfällig und verwendbar bleiben werden.
Bobby Cooke & Dylan Tran – Unterstützung bei der operativen Umsetzung des Ausnutzens
Dylan Tran – Diagrammerstellung
Chris Spehn– Integration dieser Nutzlast in unsere CI/CD-Pipeline (und all die anderen undankbaren DevOps-Arbeiten, die Sie für das Team gemacht haben)
jeffssh – Inspiration
j j – Ich bin ein meisterhafter V8-Hacker, dessen produktive V8-PoCs enorm geholfen haben