Node inspector/CEF debug abuse
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
De la documentación: Cuando se inicia con el interruptor --inspect, un proceso de Node.js escucha a un cliente de depuración. Por defecto, escuchará en el host y puerto 127.0.0.1:9229. Cada proceso también se asigna un UUID único.
Los clientes del inspector deben conocer y especificar la dirección del host, el puerto y el UUID para conectarse. Una URL completa se verá algo así como ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e.
Dado que el depurador tiene acceso completo al entorno de ejecución de Node.js, un actor malicioso capaz de conectarse a este puerto puede ser capaz de ejecutar código arbitrario en nombre del proceso de Node.js (posible escalada de privilegios).
Hay varias formas de iniciar un inspector:
Cuando inicias un proceso inspeccionado, algo como esto aparecerá:
Los procesos basados en CEF (Chromium Embedded Framework) necesitan usar el parámetro: --remote-debugging-port=9222 para abrir el debugger (las protecciones SSRF permanecen muy similares). Sin embargo, en lugar de otorgar una sesión de debug de NodeJS, se comunicarán con el navegador utilizando el Chrome DevTools Protocol, esta es una interfaz para controlar el navegador, pero no hay un RCE directo.
Cuando inicias un navegador depurado, aparecerá algo como esto:
Los sitios web abiertos en un navegador web pueden hacer solicitudes WebSocket y HTTP bajo el modelo de seguridad del navegador. Una conexión HTTP inicial es necesaria para obtener un id de sesión de depurador único. La política de mismo origen previene que los sitios web puedan hacer esta conexión HTTP. Para mayor seguridad contra ataques de reencaminamiento DNS, Node.js verifica que los encabezados 'Host' para la conexión especifiquen ya sea una dirección IP o localhost o localhost6 precisamente.
Estas medidas de seguridad previenen la explotación del inspector para ejecutar código simplemente enviando una solicitud HTTP (lo cual podría hacerse explotando una vulnerabilidad SSRF).
Puedes enviar la señal SIGUSR1 a un proceso nodejs en ejecución para hacer que inicie el inspector en el puerto predeterminado. Sin embargo, ten en cuenta que necesitas tener suficientes privilegios, por lo que esto podría otorgarte acceso privilegiado a información dentro del proceso pero no una escalada de privilegios directa.
Esto es útil en contenedores porque cerrar el proceso y comenzar uno nuevo con --inspect no es una opción porque el contenedor será eliminado junto con el proceso.
Para conectarse a un navegador basado en Chromium, se pueden acceder a las URLs chrome://inspect o edge://inspect para Chrome o Edge, respectivamente. Al hacer clic en el botón Configurar, se debe asegurar que el host y puerto objetivo estén correctamente listados. La imagen muestra un ejemplo de Ejecución Remota de Código (RCE):
Usando la línea de comandos puedes conectarte a un debugger/inspector con:
La herramienta https://github.com/taviso/cefdebug permite encontrar inspectores que se ejecutan localmente y inyectar código en ellos.
Nota que los exploits de RCE de NodeJS no funcionarán si están conectados a un navegador a través del Protocolo de DevTools de Chrome (necesitas revisar la API para encontrar cosas interesantes que hacer con ella).
Si llegaste aquí buscando cómo obtener RCE de un XSS en Electron, por favor revisa esta página.
Algunas formas comunes de obtener RCE cuando puedes conectarte a un inspector de Node es usando algo como (parece que esto no funcionará en una conexión al protocolo de DevTools de Chrome):
Puedes consultar la API aquí: https://chromedevtools.github.io/devtools-protocol/ En esta sección solo listaré cosas interesantes que he encontrado que la gente ha utilizado para explotar este protocolo.
En el CVE-2021-38112 Rhino security descubrió que una aplicación basada en CEF registró un URI personalizado en el sistema (workspaces://) que recibía el URI completo y luego lanzaba la aplicación basada en CEF con una configuración que se construía parcialmente a partir de ese URI.
Se descubrió que los parámetros del URI eran decodificados y utilizados para lanzar la aplicación básica de CEF, permitiendo a un usuario inyectar la bandera --gpu-launcher en la línea de comandos y ejecutar cosas arbitrarias.
Así que, una carga útil como:
Ejecutará un calc.exe.
Cambia la carpeta donde se van a guardar los archivos descargados y descarga un archivo para sobrescribir el código fuente de la aplicación que se usa con frecuencia con tu código malicioso.
Según esta publicación: https://medium.com/@knownsec404team/counter-webdriver-from-bot-to-rce-b5bfb309d148 es posible obtener RCE y exfiltrar páginas internas de theriver.
En un entorno real y después de comprometer una PC de usuario que utiliza un navegador basado en Chrome/Chromium, podrías lanzar un proceso de Chrome con la depuración activada y redirigir el puerto de depuración para que puedas acceder a él. De esta manera, podrás inspeccionar todo lo que la víctima hace con Chrome y robar información sensible.
La forma sigilosa es terminar todos los procesos de Chrome y luego llamar a algo como
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
