Node inspector/CEF debug abuse
Informations de base
D'après la documentation : Lorsqu'il est lancé avec l'option --inspect
, un processus Node.js écoute un client de débogage. Par défaut, il écoutera à l'hôte et au port 127.0.0.1:9229
. Chaque processus se voit également attribuer un UUID unique.
Les clients de l'inspecteur doivent connaître et spécifier l'adresse de l'hôte, le port et l'UUID pour se connecter. Une URL complète ressemblera à quelque chose comme ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e
.
Étant donné que le débogueur a un accès complet à l'environnement d'exécution de Node.js, un acteur malveillant capable de se connecter à ce port pourrait être en mesure d'exécuter du code arbitraire au nom du processus Node.js (élévation potentielle des privilèges).
Il existe plusieurs façons de démarrer un inspecteur :
Lorsque vous démarrez un processus inspecté, quelque chose comme ceci apparaîtra :
Les processus basés sur CEF (Chromium Embedded Framework) comme ont besoin d'utiliser le paramètre : --remote-debugging-port=9222
pour ouvrir le débogueur (les protections SSRF restent très similaires). Cependant, au lieu d'accorder une session de débogage NodeJS, ils communiqueront avec le navigateur en utilisant le Chrome DevTools Protocol, c'est une interface pour contrôler le navigateur, mais il n'y a pas de RCE direct.
Lorsque vous démarrez un navigateur en mode débogage, quelque chose comme ceci apparaîtra :
Navigateurs, WebSockets et politique de même origine
Les sites Web ouverts dans un navigateur Web peuvent effectuer des requêtes WebSocket et HTTP sous le modèle de sécurité du navigateur. Une connexion HTTP initiale est nécessaire pour obtenir un identifiant de session de débogueur unique. La politique de même origine empêche les sites Web de pouvoir effectuer cette connexion HTTP. Pour une sécurité supplémentaire contre les attaques de rebinding DNS, Node.js vérifie que les en-têtes 'Host' de la connexion spécifient soit une adresse IP soit localhost
ou localhost6
précisément.
Ces mesures de sécurité empêchent l'exploitation de l'inspecteur pour exécuter du code en envoyant simplement une requête HTTP (ce qui pourrait être fait en exploitant une vulnérabilité SSRF).
Démarrage de l'inspecteur dans les processus en cours d'exécution
Vous pouvez envoyer le signal SIGUSR1 à un processus nodejs en cours d'exécution pour le faire démarrer l'inspecteur sur le port par défaut. Cependant, notez que vous devez disposer de suffisamment de privilèges, cela pourrait vous accorder un accès privilégié aux informations à l'intérieur du processus mais pas une élévation de privilèges directe.
Ceci est utile dans les conteneurs car arrêter le processus et en démarrer un nouveau avec --inspect
n'est pas une option car le conteneur sera tué avec le processus.
Se connecter à l'inspecteur/debugger
Pour se connecter à un navigateur basé sur Chromium, les URL chrome://inspect
ou edge://inspect
peuvent être utilisées pour Chrome ou Edge, respectivement. En cliquant sur le bouton Configurer, il faut s'assurer que l'hôte cible et le port sont correctement répertoriés. L'image montre un exemple d'Exécution de Code à Distance (RCE) :
En utilisant la ligne de commande, vous pouvez vous connecter à un debugger/inspecteur avec :
L'outil https://github.com/taviso/cefdebug, permet de trouver des inspecteurs s'exécutant localement et d'injecter du code en eux.
Notez que les exploits RCE de NodeJS ne fonctionneront pas s'ils sont connectés à un navigateur via le Chrome DevTools Protocol (vous devez vérifier l'API pour trouver des choses intéressantes à faire avec).
RCE dans le débogueur/inspecteur NodeJS
Si vous êtes ici pour savoir comment obtenir RCE à partir d'une XSS dans Electron, veuillez consulter cette page.
Quelques moyens courants d'obtenir RCE lorsque vous pouvez vous connecter à un inspecteur Node sont d'utiliser quelque chose comme (il semble que cela ne fonctionnera pas dans une connexion au protocole Chrome DevTools):
Charges utiles du protocole Chrome DevTools
Vous pouvez consulter l'API ici : https://chromedevtools.github.io/devtools-protocol/ Dans cette section, je vais simplement répertorier les choses intéressantes que je trouve que les gens ont utilisées pour exploiter ce protocole.
Injection de paramètres via des liens profonds
Dans le CVE-2021-38112 Rhino Security a découvert qu'une application basée sur CEF enregistrait un URI personnalisé dans le système (workspaces://) qui recevait l'URI complet et ensuite lançait l'application basée sur CEF avec une configuration partiellement construite à partir de cet URI.
Il a été découvert que les paramètres de l'URI étaient décodés en URL et utilisés pour lancer l'application de base CEF, permettant à un utilisateur d'injecter le drapeau --gpu-launcher
dans la ligne de commande et d'exécuter des choses arbitraires.
Ainsi, une charge utile comme :
Écraser les fichiers
Changer le dossier où les fichiers téléchargés seront enregistrés et télécharger un fichier pour écraser le code source fréquemment utilisé de l'application avec votre code malveillant.
RCE et exfiltration de données via Webdriver
Selon cet article : https://medium.com/@knownsec404team/counter-webdriver-from-bot-to-rce-b5bfb309d148, il est possible d'obtenir une RCE et d'exfiltrer des pages internes à partir de theriver.
Post-Exploitation
Dans un environnement réel et après avoir compromis un PC utilisateur utilisant un navigateur basé sur Chrome/Chromium, vous pourriez lancer un processus Chrome avec le débogage activé et rediriger le port de débogage pour y accéder. De cette manière, vous pourrez inspecter tout ce que la victime fait avec Chrome et voler des informations sensibles.
La méthode furtive consiste à mettre fin à chaque processus Chrome puis à appeler quelque chose comme
Références
Last updated