macOS Electron Applications Injection
Last updated
Last updated
Lernen und üben Sie AWS-Hacking: HackTricks Training AWS Red Team Expert (ARTE) Lernen und üben Sie GCP-Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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 Umgebungsvariable ELECTRON_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 geladene asar-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ßlich default_app.asar nur app.asar überprüft und verwendet. Dadurch wird sichergestellt, dass bei Kombination mit der embeddedAsarIntegrityValidation-Sicherung es unmöglich ist, nicht validierten Code zu laden.
LoadBrowserProcessSpecificV8Snapshot: Wenn aktiviert, verwendet der Browserprozess die Datei namens browser_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.
Sie können diese Flags von einer Anwendung aus überprüfen:
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.
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 Sicherungen embeddedAsarIntegrityValidation und onlyLoadAppFromAsar 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:
ELECTRON_RUN_AS_NODEGemäß 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.
Wie hier vorgeschlagen könnten Sie diese Umgebungsvariable in einer Plist missbrauchen, um die Persistenz aufrechtzuerhalten:
NODE_OPTIONSSie 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.
Sie könnten diese Umgebungsvariable in einer Plist missbrauchen, um Persistenz hinzuzufügen, indem Sie diese Schlüssel hinzufügen:
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.
Sie könnten diese Umgebungsvariable in einer Plist missbrauchen, um Persistenz zu erhalten, indem Sie diese Schlüssel hinzufügen:
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).
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.
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:
Lernen & Üben Sie AWS-Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & Üben Sie GCP-Hacking: HackTricks Training GCP Red Team Expert (GRTE)
