macOS Electron Applications Injection
Grundlegende Informationen
Wenn Sie nicht wissen, was Electron ist, finden Sie hier viele Informationen. Aber für den Moment 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. Dadurch wird sichergestellt, dass bei Kombination mit derembeddedAsarIntegrityValidation
-Sicherung 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 mithilfe von 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
Sie könnten diese Datei in https://hexed.it/ laden und nach dem vorherigen String suchen. Nach diesem String können Sie im ASCII-Format eine Zahl "0" oder "1" sehen, die angibt, ob jede Sicherung deaktiviert oder aktiviert ist. Ändern Sie einfach den Hex-Code (0x30
ist 0
und 0x31
ist 1
), um die Sicherungswerte zu ändern.
Beachten Sie, dass wenn Sie versuchen, die Electron Framework
-Binärdatei innerhalb einer Anwendung mit diesen geänderten Bytes zu überschreiben, die App nicht gestartet wird.
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 also 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, daher ist dies standardmäßig nicht mehr möglich.Die kompilierte
asap
-Datei hat normalerweise die SicherungenembeddedAsarIntegrityValidation
undonlyLoadAppFromAsar
aktiviert.
Dies macht diesen Angriffsweg komplizierter (oder unmöglich).
Beachten Sie, dass es möglich ist, die Anforderung von kTCCServiceSystemPolicyAppBundles
zu umgehen, indem Sie die Anwendung in ein anderes Verzeichnis kopieren (wie /tmp
), den Ordner app.app/Contents
in app.app/NotCon
umbenennen, die asar-Datei mit Ihrem bösartigen Code ändern, sie wieder in app.app/Contents
umbenennen und ausführen.
Sie können den Code aus der asar-Datei entpacken mit:
Und packen Sie es nach der Modifikation wieder 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.
Injektion 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, die ebenfalls ignoriert wird, wenn die Sicherung RunAsNode
deaktiviert ist.
Sie könnten jedoch immer noch den Electron-Parameter --remote-debugging-port=9229
verwenden, aber das vorherige Payload 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 zu stehlen, wie die Verlauf (mit GET-Befehlen) oder die Cookies des Browsers (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 Ausnutzung ä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