Node inspector/CEF debug abuse
Información Básica
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
. A cada proceso también se le 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 en modo depuración, aparecerá algo como esto:
Browsers, WebSockets y política de mismo origen
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 que podría hacerse explotando una vulnerabilidad SSRF).
Iniciando el inspector en procesos en ejecución
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 detener el proceso y comenzar uno nuevo con --inspect
no es una opción porque el contenedor será eliminado junto con el proceso.
Conectar al inspector/debugger
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).
RCE en el Depurador/Inspector de NodeJS
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):
Chrome DevTools Protocol Payloads
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.
Inyección de Parámetros a través de Deep Links
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.
Sobrescribir Archivos
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.
Webdriver RCE y exfiltración
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.
Post-Explotación
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 cada proceso de Chrome y luego llamar a algo como
Referencias
Last updated