Electron Desktop Apps
Last updated
Last updated
Electron combine un backend local (avec NodeJS) et un frontend (Chromium), bien qu'il manque certains mécanismes de sécurité des navigateurs modernes.
Généralement, vous pouvez trouver le code de l'application Electron à l'intérieur d'une application .asar, pour obtenir le code, vous devez l'extraire :
Dans le code source d'une application Electron, à l'intérieur de packet.json, vous pouvez trouver spécifié le fichier main.js où les configurations de sécurité sont définies.
Electron a 2 types de processus :
Processus principal (a un accès complet à NodeJS)
Processus de rendu (devrait avoir un accès restreint à NodeJS pour des raisons de sécurité)
Un processus de rendu sera une fenêtre de navigateur chargeant un fichier :
Les paramètres du processus de rendu peuvent être configurés dans le processus principal à l'intérieur du fichier main.js. Certaines des configurations permettront d'empêcher l'application Electron de subir une RCE ou d'autres vulnérabilités si les paramètres sont correctement configurés.
L'application Electron pourrait accéder au périphérique via les API Node bien qu'il puisse être configuré pour l'empêcher :
nodeIntegration - est désactivé par défaut. S'il est activé, cela permet d'accéder aux fonctionnalités de Node depuis le processus de rendu.
contextIsolation - est activé par défaut. S'il est désactivé, les processus principal et de rendu ne sont pas isolés.
preload - vide par défaut.
sandbox - est désactivé par défaut. Cela restreindra les actions que NodeJS peut effectuer.
Intégration de Node dans les Workers
nodeIntegrationInSubframes - est désactivé par défaut.
Si nodeIntegration est activé, cela permettrait l'utilisation des API Node.js dans les pages web qui sont chargées dans des iframes au sein d'une application Electron.
Si nodeIntegration est désactivé, alors les préchargements se chargeront dans l'iframe
Exemple de configuration :
Certains payloads RCE provenant de ici :
Modifier la configuration start-main et ajouter l'utilisation d'un proxy tel que :
Si vous pouvez exécuter localement une application Electron, il est possible que vous puissiez lui faire exécuter du code JavaScript arbitraire. Vérifiez comment faire dans:
macOS Electron Applications InjectionSi nodeIntegration est défini sur on, le JavaScript d'une page web peut facilement utiliser les fonctionnalités de Node.js en appelant simplement require(). Par exemple, la manière d'exécuter l'application calc sur Windows est la suivante:
Le script indiqué dans ce paramètre est chargé avant les autres scripts dans le moteur de rendu, il a donc un accès illimité aux APIs Node:
Par conséquent, le script peut exporter les fonctionnalités du nœud vers les pages :
Si contextIsolation est activé, cela ne fonctionnera pas
La contextIsolation introduit les contextes séparés entre les scripts de la page web et le code interne JavaScript d'Electron de sorte que l'exécution JavaScript de chaque code n'affecte pas l'autre. Il s'agit d'une fonctionnalité nécessaire pour éliminer la possibilité de RCE.
Si les contextes ne sont pas isolés, un attaquant peut :
Exécuter du JavaScript arbitraire dans le renderer (XSS ou navigation vers des sites externes)
Écraser la méthode intégrée utilisée dans le preload ou le code interne d'Electron par sa propre fonction
Déclencher l'utilisation de la fonction écrasée
RCE ?
Il existe 2 endroits où les méthodes intégrées peuvent être écrasées : dans le code de préchargement ou dans le code interne d'Electron :
Electron contextIsolation RCE via preload codeElectron contextIsolation RCE via Electron internal codeElectron contextIsolation RCE via IPCSi des restrictions sont appliquées lorsque vous cliquez sur un lien, vous pourriez être en mesure de les contourner en faisant un clic du milieu au lieu d'un clic gauche régulier
Pour plus d'informations sur ces exemples, consultez https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8 et https://benjamin-altpeter.de/shell-openexternal-dangers/
Lors du déploiement d'une application de bureau Electron, il est crucial de garantir les paramètres corrects pour nodeIntegration et contextIsolation. Il est établi que l'exécution de code à distance côté client (RCE) ciblant les scripts de préchargement ou le code natif d'Electron à partir du processus principal est efficacement empêchée avec ces paramètres en place.
Lorsqu'un utilisateur interagit avec des liens ou ouvre de nouvelles fenêtres, des écouteurs d'événements spécifiques sont déclenchés, ce qui est crucial pour la sécurité et la fonctionnalité de l'application:
Ces écouteurs sont remplacés par l'application de bureau pour implémenter sa propre logique métier. L'application évalue si un lien navigué doit être ouvert en interne ou dans un navigateur web externe. Cette décision est généralement prise via une fonction, openInternally. Si cette fonction renvoie false, cela indique que le lien doit être ouvert en externe, en utilisant la fonction shell.openExternal.
Voici un pseudocode simplifié :
Les meilleures pratiques de sécurité d'Electron JS déconseillent d'accepter du contenu non fiable avec la fonction openExternal, car cela pourrait entraîner une RCE via divers protocoles. Les systèmes d'exploitation prennent en charge différents protocoles qui pourraient déclencher une RCE. Pour des exemples détaillés et une explication approfondie sur ce sujet, on peut se référer à cette ressource, qui inclut des exemples de protocoles Windows capables d'exploiter cette vulnérabilité.
Les exemples d'exploits de protocoles Windows incluent :
La désactivation de contextIsolation permet l'utilisation des balises <webview>, similaire à <iframe>, pour lire et exfiltrer des fichiers locaux. Un exemple fourni démontre comment exploiter cette vulnérabilité pour lire le contenu des fichiers internes :
De plus, une autre méthode pour lire un fichier interne est partagée, mettant en évidence une vulnérabilité critique de lecture de fichiers locaux dans une application de bureau Electron. Cela implique l'injection d'un script pour exploiter l'application et exfiltrer des données :
Si le chromium utilisé par l'application est ancien et qu'il existe des vulnérabilités connues sur celui-ci, il pourrait être possible de l'exploiter et d'obtenir une RCE via un XSS. Vous pouvez voir un exemple dans ce writeup: https://blog.electrovolt.io/posts/discord-rce/
Supposons que vous ayez trouvé un XSS mais que vous ne pouvez pas déclencher de RCE ou voler des fichiers internes, vous pourriez essayer de l'utiliser pour voler des informations d'identification via du phishing.
Tout d'abord, vous devez savoir ce qui se passe lorsque vous essayez d'ouvrir une nouvelle URL, en vérifiant le code JS dans le front-end:
L'appel à openInternally décidera si le lien sera ouvert dans la fenêtre du bureau car il s'agit d'un lien appartenant à la plateforme, ou s'il sera ouvert dans le navigateur en tant que ressource tierce.
Dans le cas où le regex utilisé par la fonction est vulnérable aux contournements (par exemple en ne fuyant pas les points des sous-domaines), un attaquant pourrait exploiter la XSS pour ouvrir une nouvelle fenêtre qui sera située dans l'infrastructure de l'attaquant demandant des informations d'identification à l'utilisateur:
Electronegativity est un outil pour identifier les mauvaises configurations et les anti-patrons de sécurité dans les applications basées sur Electron.
Electrolint est un plugin open source pour VS Code pour les applications Electron qui utilise Electronegativity.
nodejsscan pour vérifier les bibliothèques tierces vulnérables.
Electro.ng: Vous devez l'acheter
Dans https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s, vous pouvez trouver un laboratoire pour exploiter des applications Electron vulnérables.
Quelques commandes qui vous aideront avec le laboratoire:
Plus de recherches et d'articles sur la sécurité d'Electron sur https://github.com/doyensec/awesome-electronjs-hacking
