macOS Electron Applications Injection
Informations de base
Si vous ne savez pas ce qu'est Electron, vous pouvez trouver beaucoup d'informations ici. Mais pour l'instant, sachez simplement qu'Electron exécute node. Et node a certains paramètres et variables d'environnement qui peuvent être utilisés pour lui faire exécuter un autre code que celui indiqué.
Fusibles Electron
Ces techniques seront discutées ensuite, mais récemment, Electron a ajouté plusieurs drapeaux de sécurité pour les prévenir. Ceux-ci sont les Fusibles Electron et ceux-ci sont utilisés pour empêcher les applications Electron sur macOS de charger un code arbitraire :
RunAsNode: S'il est désactivé, il empêche l'utilisation de la variable d'environnementELECTRON_RUN_AS_NODEpour injecter du code.EnableNodeCliInspectArguments: S'il est désactivé, des paramètres comme--inspect,--inspect-brkne seront pas respectés. Évitant ainsi l'injection de code.EnableEmbeddedAsarIntegrityValidation: S'il est activé, le fichierasarchargé sera validé par macOS. Empêchant ainsi l'injection de code en modifiant le contenu de ce fichier.OnlyLoadAppFromAsar: S'il est activé, au lieu de rechercher le chargement dans l'ordre suivant :app.asar,appet enfindefault_app.asar. Il vérifiera et utilisera uniquement app.asar, garantissant ainsi que lorsqu'il est combiné avec le fusibleembeddedAsarIntegrityValidation, il est impossible de charger un code non validé.LoadBrowserProcessSpecificV8Snapshot: S'il est activé, le processus du navigateur utilise le fichier appelébrowser_v8_context_snapshot.binpour son instantané V8.
Un autre fusible intéressant qui ne préviendra pas l'injection de code est :
EnableCookieEncryption : S'il est activé, le stockage des cookies sur le disque est chiffré à l'aide de clés de cryptographie au niveau du système d'exploitation.
Vérification des fusibles Electron
Vous pouvez vérifier ces drapeaux à partir d'une application avec :
Modification des Fusibles Electron
Comme le document mentionne, la configuration des Fusibles Electron est configurée à l'intérieur du binaire Electron qui contient quelque part la chaîne dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX.
Dans les applications macOS, cela se trouve généralement dans application.app/Contents/Frameworks/Electron Framework.framework/Electron Framework
Vous pouvez charger ce fichier dans https://hexed.it/ et rechercher la chaîne précédente. Après cette chaîne, vous pouvez voir en ASCII un nombre "0" ou "1" indiquant si chaque fusible est désactivé ou activé. Modifiez simplement le code hexadécimal (0x30 est 0 et 0x31 est 1) pour modifier les valeurs des fusibles.
Notez que si vous essayez de remplacer le binaire du framework Electron à l'intérieur d'une application avec ces octets modifiés, l'application ne se lancera pas.
RCE ajout de code aux applications Electron
Il pourrait y avoir des fichiers JS/HTML externes qu'une application Electron utilise, donc un attaquant pourrait injecter du code dans ces fichiers dont la signature ne sera pas vérifiée et exécuter du code arbitraire dans le contexte de l'application.
Cependant, actuellement, il y a 2 limitations :
L'autorisation
kTCCServiceSystemPolicyAppBundlesest nécessaire pour modifier une application, donc par défaut cela n'est plus possible.Le fichier compilé
asapa généralement les fusiblesembeddedAsarIntegrityValidationetonlyLoadAppFromAsaractivés
Ce qui rend ce chemin d'attaque plus compliqué (ou impossible).
Notez qu'il est possible de contourner l'exigence de kTCCServiceSystemPolicyAppBundles en copiant l'application dans un autre répertoire (comme /tmp), en renommant le dossier app.app/Contents en app.app/NotCon, en modifiant le fichier asar avec votre code malveillant, en le renommant en app.app/Contents et en l'exécutant.
Vous pouvez extraire le code du fichier asar avec :
Et recompilez-le après l'avoir modifié avec :
RCE avec ELECTRON_RUN_AS_NODE
ELECTRON_RUN_AS_NODESelon la documentation, si cette variable d'environnement est définie, elle démarrera le processus en tant que processus Node.js normal.
Si le fusible RunAsNode est désactivé, la variable d'environnement ELECTRON_RUN_AS_NODE sera ignorée et cela ne fonctionnera pas.
Injection depuis le fichier Plist de l'application
Comme proposé ici, vous pourriez abuser de cette variable d'environnement dans un fichier plist pour maintenir la persistance :
RCE avec NODE_OPTIONS
NODE_OPTIONSVous pouvez stocker la charge utile dans un fichier différent et l'exécuter :
Si le fusible EnableNodeOptionsEnvironmentVariable est désactivé, l'application ignorera la variable d'environnement NODE_OPTIONS lors du lancement, sauf si la variable d'environnement ELECTRON_RUN_AS_NODE est définie, ce qui sera également ignoré si le fusible RunAsNode est désactivé.
Si vous ne définissez pas ELECTRON_RUN_AS_NODE, vous rencontrerez l'erreur suivante : La plupart des options NODE ne sont pas prises en charge dans les applications packagées. Voir la documentation pour plus de détails.
Injection depuis le fichier Plist de l'application
Vous pourriez abuser de cette variable d'environnement dans un fichier plist pour maintenir la persistance en ajoutant ces clés :
RCE avec l'inspection
Selon ceci, si vous exécutez une application Electron avec des indicateurs tels que --inspect, --inspect-brk et --remote-debugging-port, un port de débogage sera ouvert afin que vous puissiez vous y connecter (par exemple depuis Chrome dans chrome://inspect) et vous pourrez injecter du code ou même lancer de nouveaux processus.
Par exemple:
Si le fusible EnableNodeCliInspectArguments est désactivé, l'application ignorera les paramètres de node (comme --inspect) lors du lancement à moins que la variable d'environnement ELECTRON_RUN_AS_NODE ne soit définie, ce qui sera également ignoré si le fusible RunAsNode est désactivé.
Cependant, vous pouvez toujours utiliser le paramètre electron --remote-debugging-port=9229 mais la charge utile précédente ne fonctionnera pas pour exécuter d'autres processus.
En utilisant le paramètre --remote-debugging-port=9222, il est possible de voler des informations de l'application Electron comme l'historique (avec des commandes GET) ou les cookies du navigateur (car ils sont décryptés à l'intérieur du navigateur et qu'il existe un point de terminaison json qui les fournira).
Vous pouvez apprendre comment faire cela ici et ici et utiliser l'outil automatique WhiteChocolateMacademiaNut ou un simple script comme :
Dans cet article de blog, ce débogage est exploité pour faire en sorte que Chrome headless télécharge des fichiers arbitraires dans des emplacements arbitraires.
Injection à partir du fichier Plist de l'application
Vous pourriez exploiter cette variable d'environnement dans un fichier plist pour maintenir la persistance en ajoutant ces clés :
Contournement de TCC en abusant des anciennes versions
Le démon TCC de macOS ne vérifie pas la version exécutée de l'application. Donc, si vous ne pouvez pas injecter de code dans une application Electron avec l'une des techniques précédentes, vous pourriez télécharger une version antérieure de l'application et y injecter du code car elle conservera toujours les privilèges TCC (sauf si le Cache de confiance l'empêche).
Exécution de code non JS
Les techniques précédentes vous permettront d'exécuter du code JS à l'intérieur du processus de l'application Electron. Cependant, rappelez-vous que les processus enfants s'exécutent sous le même profil de bac à sable que l'application parente et héritent de leurs autorisations TCC. Par conséquent, si vous souhaitez abuser des autorisations pour accéder à la caméra ou au microphone par exemple, vous pourriez simplement exécuter un autre binaire à partir du processus.
Injection automatique
L'outil electroniz3r peut être facilement utilisé pour trouver des applications Electron vulnérables installées et injecter du code dessus. Cet outil essaiera d'utiliser la technique --inspect :
Vous devez le compiler vous-même et pouvez l'utiliser de cette manière :
Références
Dernière mise à jour
