macOS Electron Applications Injection
Grundlegende Informationen
Wenn Sie nicht wissen, was Electron ist, finden Sie hier viele Informationen. Aber vorerst wissen Sie einfach, dass Electron node ausführt. Und node hat einige Parameter und Umgebungsvariablen, die verwendet werden können, um es dazu zu bringen, anderen Code auszuführen als die angegebene Datei.
Electron-Sicherungen
Diese Techniken werden als nächstes diskutiert, aber in letzter Zeit hat Electron mehrere Sicherheitsflags hinzugefügt, um sie zu verhindern. Dies sind die Electron-Sicherungen und diese werden verwendet, um zu verhindern, dass Electron-Apps in macOS beliebigen Code laden:
RunAsNode
: Wenn deaktiviert, verhindert es die Verwendung der UmgebungsvariableELECTRON_RUN_AS_NODE
zum Einspritzen von Code.EnableNodeCliInspectArguments
: Wenn deaktiviert, werden Parameter wie--inspect
,--inspect-brk
nicht respektiert. Auf diese Weise wird das Einspritzen von Code vermieden.EnableEmbeddedAsarIntegrityValidation
: Wenn aktiviert, wird die geladeneasar
-Datei von macOS validiert. Auf diese Weise wird das Einspritzen von Code verhindert, indem der Inhalt dieser Datei geändert wird.OnlyLoadAppFromAsar
: Wenn dies aktiviert ist, wird anstelle der Suche nach dem Laden in folgender Reihenfolge:app.asar
,app
und schließlichdefault_app.asar
nur app.asar überprüft und verwendet, wodurch sichergestellt wird, dass bei Kombination mit der SicherungembeddedAsarIntegrityValidation
es unmöglich ist, nicht validierten Code zu laden.LoadBrowserProcessSpecificV8Snapshot
: Wenn aktiviert, verwendet der Browserprozess die Datei namensbrowser_v8_context_snapshot.bin
für seinen V8-Snapshot.
Eine weitere interessante Sicherung, die das Einspritzen von Code nicht verhindern wird, ist:
EnableCookieEncryption: Wenn aktiviert, wird der Cookie-Speicher auf der Festplatte mit kryptografischen Schlüsseln auf OS-Ebene verschlüsselt.
Überprüfen der Electron-Sicherungen
Sie können diese Flags von einer Anwendung aus überprüfen:
Modifizieren von Electron-Sicherungen
Wie in den Dokumenten erwähnt, werden die Konfigurationen der Electron-Sicherungen innerhalb der Electron-Binärdatei konfiguriert, die irgendwo den String dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX
enthält.
In macOS-Anwendungen befindet sich dies normalerweise in Anwendung.app/Inhalte/Frameworks/Electron Framework.framework/Electron Framework
RCE Hinzufügen von Code zu Electron-Anwendungen
Es könnten externe JS/HTML-Dateien vorhanden sein, die eine Electron-App verwendet. Ein Angreifer könnte Code in diese Dateien einschleusen, dessen Signatur nicht überprüft wird, und beliebigen Code im Kontext der App ausführen.
Es gibt jedoch derzeit 2 Einschränkungen:
Die Berechtigung
kTCCServiceSystemPolicyAppBundles
ist erforderlich, um eine App zu modifizieren. Standardmäßig ist dies nicht mehr möglich.Die kompilierte Datei
asap
hat normalerweise die FusesembeddedAsarIntegrityValidation
undonlyLoadAppFromAsar
aktiviert, was diesen Angriffsweg komplizierter (oder unmöglich) macht.
Es ist möglich, die Anforderung von kTCCServiceSystemPolicyAppBundles
zu umgehen, indem die Anwendung in ein anderes Verzeichnis kopiert wird (z. B. /tmp
), den Ordner app.app/Contents
in app.app/NotCon
umbenannt, die asar-Datei mit Ihrem bösartigen Code modifiziert, sie wieder in app.app/Contents
umbenannt und ausgeführt wird.
Sie können den Code aus der asar-Datei entpacken mit:
Und packen Sie es nach der Modifikation mit:
RCE mit ELECTRON_RUN_AS_NODE
ELECTRON_RUN_AS_NODE
Gemäß der Dokumentation wird, wenn diese Umgebungsvariable gesetzt ist, der Prozess als normaler Node.js-Prozess gestartet.
Wenn die Sicherung RunAsNode
deaktiviert ist, wird die Umgebungsvariable ELECTRON_RUN_AS_NODE
ignoriert und dies funktioniert nicht.
Injection aus der App-Plist
Wie hier vorgeschlagen könnten Sie diese Umgebungsvariable in einer Plist missbrauchen, um die Persistenz aufrechtzuerhalten:
RCE mit NODE_OPTIONS
NODE_OPTIONS
Sie können das Payload in einer anderen Datei speichern und ausführen:
Wenn die Sicherung EnableNodeOptionsEnvironmentVariable
deaktiviert ist, wird die App die Umgebungsvariable NODE_OPTIONS beim Start ignorieren, es sei denn, die Umgebungsvariable ELECTRON_RUN_AS_NODE
ist gesetzt, was auch ignoriert wird, wenn die Sicherung RunAsNode
deaktiviert ist.
Wenn Sie ELECTRON_RUN_AS_NODE
nicht setzen, erhalten Sie den Fehler: Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
Injektion aus der App-Plist
Sie könnten diese Umgebungsvariable in einer Plist missbrauchen, um Persistenz hinzuzufügen, indem Sie diese Schlüssel hinzufügen:
RCE mit Inspektion
Gemäß diesem Artikel, wenn Sie eine Electron-Anwendung mit Flaggen wie --inspect
, --inspect-brk
und --remote-debugging-port
ausführen, wird ein Debug-Port geöffnet, sodass Sie sich damit verbinden können (zum Beispiel von Chrome aus unter chrome://inspect
) und Sie werden in der Lage sein, Code einzuspritzen oder sogar neue Prozesse zu starten.
Zum Beispiel:
Wenn die Sicherung EnableNodeCliInspectArguments
deaktiviert ist, ignoriert die App Node-Parameter (wie --inspect
), wenn sie gestartet wird, es sei denn, die Umgebungsvariable ELECTRON_RUN_AS_NODE
ist gesetzt, was auch ignoriert wird, wenn die Sicherung RunAsNode
deaktiviert ist.
Sie könnten jedoch immer noch den Electron-Parameter --remote-debugging-port=9229
verwenden, aber die vorherige Nutzlast funktioniert nicht, um andere Prozesse auszuführen.
Durch die Verwendung des Parameters --remote-debugging-port=9222
ist es möglich, einige Informationen aus der Electron-App wie die Verlauf (mit GET-Befehlen) oder die Cookies des Browsers zu stehlen (da sie im Browser entschlüsselt sind und es einen JSON-Endpunkt gibt, der sie liefert).
Sie können lernen, wie das geht in hier und hier und das automatische Tool WhiteChocolateMacademiaNut oder ein einfaches Skript wie:
In diesem Blogbeitrag wird dieses Debugging missbraucht, um einen headless Chrome beliebige Dateien an beliebigen Orten herunterladen zu lassen.
Injection aus der App-Plist
Sie könnten diese Umgebungsvariable in einer Plist missbrauchen, um Persistenz zu erhalten, indem Sie diese Schlüssel hinzufügen:
TCC Umgehung durch Ausnutzen älterer Versionen
Der TCC-Dämon von macOS überprüft nicht die ausgeführte Version der Anwendung. Wenn Sie also keinen Code in einer Electron-Anwendung injizieren können mit einer der vorherigen Techniken, könnten Sie eine frühere Version der APP herunterladen und Code darauf injizieren, da sie immer noch die TCC-Berechtigungen erhält (sofern der Trust Cache dies nicht verhindert).
Ausführen von nicht-JS-Code
Die vorherigen Techniken ermöglichen es Ihnen, JS-Code im Prozess der Electron-Anwendung auszuführen. Denken Sie jedoch daran, dass die Unterprozesse unter demselben Sandbox-Profil wie die übergeordnete Anwendung ausgeführt werden und deren TCC-Berechtigungen erben. Daher könnten Sie, wenn Sie Berechtigungen missbrauchen möchten, um beispielsweise auf Kamera oder Mikrofon zuzugreifen, einfach eine andere Binärdatei aus dem Prozess heraus ausführen.
Automatische Injektion
Das Tool electroniz3r kann einfach verwendet werden, um anfällige Electron-Anwendungen zu finden, die installiert sind, und Code darauf zu injizieren. Dieses Tool wird versuchen, die --inspect
-Technik zu verwenden:
Sie müssen es selbst kompilieren und können es wie folgt verwenden:
Referenzen
Last updated