5 Formas en las que Podrías Haber Hackeado Node.js

Hola a todos. Mi nombre es Rafael Gonzaga. Soy ingeniero en Neo4m. Soy de Brasil. Soy miembro de algunas organizaciones de código abierto y soy miembro del DSC de Node.js, líder del grupo de trabajo de seguridad. Soy un lanzador de Node.js, así que si alguna de las compilaciones de Node.js te rompe, probablemente fue por mi culpa, ¿OK?

Así que recientemente, comencé a codificar en vivo en Twitch. Así que si te gusta este tipo de contenido, sígueme allí también. Estoy disponible en la mayoría de las redes sociales.

Entonces, OK, en primer lugar, antes de mostrar las partes malas de Node.js, me gustaría dar un descargo de responsabilidad diciendo que todos los lenguajes lo tienen e introducir un concepto de seguridad en el lenguaje de programación. Por ejemplo, en primer lugar, todas las CV mencionadas aquí fueron abordadas, ¿OK? Asegúrate de estar utilizando una versión segura de Node.js. Por ejemplo, escribí un paquete llamado IsMyNodeVulnerable. Si solo llamas a npx is my node vulnerable, podrás ver si estás utilizando una versión vulnerable de Node.js. Si es así, por favor actualiza, ¿OK?

Entonces, en primer lugar, presentaré al equipo de seguridad de Node.js. Básicamente, el equipo de seguridad de Node.js consta de dos grupos. El primero es el equipo de evaluación de Node.js. Está compuesto por el Comité Directivo Técnico de Node.js, contribuyentes específicos de Node.js con experiencia en seguridad, el equipo de lanzamiento de Node.js y el equipo de construcción, ¿OK? Y el segundo grupo es el grupo de trabajo de seguridad. Es un grupo de trabajo de la comunidad. Trabajamos en varias iniciativas de seguridad, y el modelo de permisos experimental o el modelo de permisos es solo uno de ellos. Puedes ser parte de él. Solo envíame un mensaje, puedes ir al repositorio y podrás verlo, ¿OK?

Entonces, vamos a lo que importa. ¿Encontraste una posible vulnerabilidad de seguridad? Por favor, no abras un problema público. Estarías divulgando la vulnerabilidad, y eso es crucial. Eso es muy malo para los mantenedores, porque necesitamos apurarnos. Necesitamos hacer muchas cosas en poco tiempo, y eventualmente es muy malo, en realidad. Así que normalmente, ve el archivo security.md en Node.js, podrás verlo. Si vas al hacker uno, también podrás verlo. Así que el proceso de presentar vulnerabilidades de Node.js es bastante sencillo, ¿OK? Encuentras una posible vulnerabilidad y vas al hacker uno. Hacker uno es una plataforma donde puedes presentar cualquier posible vulnerabilidad y evaluarla. Y luego llenas el formulario, y el equipo de evaluación de Node.js recibe tu informe. Y lo evaluamos contra nuestro modelo de amenazas.

Y si eso se acepta, prepararemos una solución de security y una liberación de security. ¿De acuerdo? Entonces, bueno, puedes ganar dinero con ello a través de programas de recompensas por errores. ¿De acuerdo?

Entonces, en esta masterclass, presentaré cinco formas en las que podrías haber hackeado Node.js. Sin embargo, es importante mencionar que todas las vulnerabilities eran una amenaza. Así que no te preocupes.

La primera es las inyecciones DLL, ¿de acuerdo? Hola, usuarios de Windows. La inyección DLL es una técnica utilizada por los hackers para inyectar archivos maliciosos de biblioteca de enlaces dinámicos en un proceso en ejecución, modificando así su comportamiento o obteniendo acceso no autorizado a sus recursos.

Entonces, tomemos este ejemplo, ¿de acuerdo? Estás en Windows. De nuevo, lo siento, usuarios de Windows. Digamos que instalas cualquier tipo de juego. La mayoría de los juegos actuales necesitan abrir SSL. Así que tienes abierto SSL en tu máquina. Y luego estás siguiendo una publicación de blog, pero escribiste mal Fastify. Y luego instalas Fastify, ¿de acuerdo? Y luego este paquete, este es un paquete malicioso que contiene un providers.dll. Y el contenido de este dll es básicamente lo más peligroso que puedes hacer en Windows, que es abrir la calculadora, ¿de acuerdo? Y luego, bueno, este paquete requiere crypto, en realidad, al principio. Siempre que requieres crypto, HTTPS o módulo TLS en Node.js, inicializará open SSL. Y cuando se inicializa, buscará providers.dll en el directorio de trabajo actual. Y por ejemplo, si el paquete, paquete malicioso, contiene solo un script de post-instalación que llama a las versiones de NPM que, bajo el capó, requieren crypto, inicializará open SSL y cargará el providers.dll y luego sucede el ataque. Ahora piensa que ya no carga providers.dll en el directorio de trabajo actual.

Así que vamos a la segunda. Hablemos de rebinding DNS. Entonces, cuando quieres visitar un sitio web como xample.com o jsnation.com, tu ordenador necesita saber la dirección IP de ese sitio web. Así que el DNS es como una guía telefónica. Para internet que ayuda a tu ordenador a encontrar la dirección IP correcta para el DNS.

Así que imagina que alguien quiere engañarte para que visites un sitio web malicioso en lugar del al que tenías previsto ir. Podrían utilizar algo llamado ataque de rebinding DNS para hacer esto. Así que supongamos que hay un usuario utilizando node-inspect. Esto abrirá el depurador de Node.js. Y luego accedes a attacker.com. Y attacker.com te redirige a una dirección IP no válida. Así que Node.js no estaba validando correctamente esa dirección IP. Así que iba al navegador. Y luego el navegador dice, OK, esta no es una dirección IP real, preguntaré al servidor DNS. El servidor DNS va a un servidor DNS con una conexión comprometida, lo que significa, OK, quiero la DNS o la dirección IP para el 10.0.2.555 en el puerto 9229. Y luego, bueno, puedes pensar, OK, el atacante tendría que tener acceso al servidor DNS y eso es difícil, en realidad no. DNS no está protegido por SSL o TLS. Así que si estás en la misma red, simplemente puede realizar un ataque de hombre en el medio.

Así que OK. Supongamos que el atacante ahora tiene acceso al servidor DNS. Y luego, cuando requieres, cuando solicitas la dirección IP para esa dirección IP no válida, mapea la solicitud a su IP de atacante con un tiempo de vida corto. ¿OK? Y luego la página intenta cargar un /JSON. El tiempo de vida es básicamente un número especial que se utiliza para asegurarse de que el mensaje enviado por Internet no quede atrapado en un bucle o siga yendo para siempre. Funciona como un temporizador que le dice al ordenador encargado de enviar el mensaje cuándo parar, intentar entregarlo si tarda demasiado. ¿OK? Así que, por ejemplo, solicito al servidor web la dirección IP de axample.com, y recibo un tiempo de vida, un tiempo de vida de, no sé, 60 segundos. Y luego si solicito la dirección IP de ese DNS en ese corto período de tiempo, antes de 60 segundos, recibo la misma IP. Si solicito la dirección IP después de los 60 segundos, realizará otra llamada DNS. ¿OK? Así que, OK. Luego está cargando el SlashJSON bajo la IP de ataque, y luego el tll expira. Y esta vez, requiere el servidor DNS de nuevo, y el atacante lo envía al local host.

Por lo tanto, expondrá el SlashJSON bajo su host local a la IP del atacante, lo que significa que mostrará la URL del WebSocketDebugger, y luego el atacante obtendrá acceso a su máquina. Y bueno, puede ejecutar lo que quiera, o ella quiera en su instancia de Node.js comprometida. Eso es muy malo. Es difícil de replicar, ¿OK? Pero sigue siendo un buen ataque. Y después de resolver esto, recibimos otro informe de que, OK, se solucionó el rebinding DNS, pero hay un caso límite en Apple, y luego lo solucionamos de nuevo. Sucede. Entonces sí. El tercero es el contrabando de solicitudes 80PS. Hagamos una analogía aquí. Imagina que estás en un restaurante, y quieres pedir una hamburguesa. Le das tu pedido al camarero, quien lo lleva a la cocina. Pero ahora imagina que alguien más en la mesa quiere pedir un refresco. Y quieren hacerlo de una manera sigilosa. Así que no lo ves. Entonces escriben una nota con el pedido del refresco y la esconden dentro de tu pedido de hamburguesa, como un mensaje secreto, ¿OK? Entonces el camarero toma tu pedido de hamburguesa y ve la nota del refresco escondida dentro. Pero como la nota está escondida, el camarero no se da cuenta de que hay dos pedidos separados. Y luego el camarero te trae una hamburguesa y un refresco, aunque solo pediste una hamburguesa, ¿OK? Hagamos eso. Hagámoslo de manera técnica ahora, ¿OK? Supongamos que solo haces una solicitud y luego tienes un CDN. Y luego tienes una red privada debajo, digamos que tengo un microservicio llamado usuarios, ¿OK? Y luego puedes tener, no sé, varios servidores. Tienes un balanceador de carga, proxy inverso. Realmente no importa. Y para que esto ocurra en la vulnerabilidad de Node.js, básicamente la codificación de transferencia era un encabezado requerido para explotarlo. Básicamente, la codificación de transferencia es un encabezado que sirve para decirle al servidor cómo interpretar los bytes en el cuerpo del encabezado de la solicitud, OK, también en el cuerpo del encabezado. Entonces imagina que hay un usuario malicioso que envía una solicitud con el siguiente contenido, publica hoy barra. Y luego uno de los encabezados es la X punto y coma barra n. Esa es la nueva línea. Esto estaba eludiendo la validación LLTP de Node.js. Entonces, Node.js estaba esperando un CLLF, que es retorno de carro-salto de línea, para separar correctamente los encabezados. Pero se envía un encabezado no válido utilizando solo LF, la barra n.

Pero aún así, Node.js lo procesa, ¿OK? Entonces, lo que estaba sucediendo detrás de escena es que, esta solicitud va al CDN, el CDN la envía al servidor, el servidor la interpreta como dos solicitudes, un POST a la barra y un GET a las cosas de administrador, aunque solo envié una solicitud.

Entonces, tal vez las cosas de administrador no estaban expuestas a la red, a la web, aunque yo podría hacer esta solicitud. Eso es terrible, ¿OK?

Entonces, el otro es intentar leer desde rutas arbitrarias. Básicamente, supongamos que estás en un host basado en Linux con varios usuarios y uno de los usuarios es malicioso, ¿OK? Sucede muy a menudo en universidades, ¿OK? Entonces, supongamos que un usuario malicioso crea un archivo falso openSSL, un archivo de configuración openSSL.cnf que contiene la configuración maliciosa. El openSSL.cnf es solo un archivo que contiene la configuración de seguridad para el openSSL, ¿OK? Entonces, el atacante puede hacer muchas cosas como modificar el generador de claves, alterar la configuración predeterminada y así sucesivamente. Y luego el usuario malicioso crea este falso openSSL.cnf en este archivo específico, io.js build ws.out.release y así sucesivamente y va a ese archivo largo. Y luego Node.js en el inicio estaba tratando de leer un archivo llamado openSSL.cnf en esa ubicación específica. Fue un error de nuestra parte. Entonces, el atacante pudo averiguarlo usando las herramientas de utilidad de Linux como strace. Lo usó para rastrear las llamadas del sistema, OK, así que simplemente llamó a strace y luego pudo ver, OK, estas son las llamadas abiertas que hace este programa específico. Y luego creo este archivo porque intentará leer este archivo específico y luego puedo hackearlo. OK, como dije, lo hemos abordado y he creado una prueba para abordar este problema. Entonces, si quieres ver el PR 46150, podrás ver cómo lo resolví.

Entonces, OK y luego OK, una vez que node.js lo carga, el atacante obtendrá acceso a ese open ssl y con una configuración personalizada. Entonces, ahora el atacante lo controla. Y OK, eso es malo. OK, es muy difícil de explicar, pero eso es malo.

El último, la validación de certificación. Personalmente, cometí este error y lo corregí, pero fue difícil. Entonces, supongamos que haces una solicitud normal. Realizas una solicitud GET al servidor y la IP del cliente es xsx porque es tu dirección IP. Pero luego quieres usar un servidor PROC. Es bastante común porque supongamos que quieres interceptar una solicitud, normalmente un servidor PROC, un depurador PROC ATP, es bueno para hacer eso. Y luego la dirección IP del cliente es diferente, es la III, la del servidor PROC. Puedes usarlo para proxies intermediarios. Hay otra herramienta llamada HTTP Toolkit Proxy. Puedes interceptar solicitudes de depuración. Eso es muy útil para los desarrolladores. Este es solo un ejemplo del proxy intermediario. Y luego supongamos que estás en una entrevista, y el entrevistador te pide que implementes un cliente de proxy HTTP, ¿OK? Y terminas con el siguiente ejemplo.

Tengo el GET HTTP y el nombre del host es básicamente la URL del PROC. Y la solicitud del servidor es el servidor en el que quiero realizar la solicitud bajo el cliente del PROC. Básicamente en una solicitud de consulta, es básicamente así. El host local es mi servidor PROC. Sin embargo, no hagas eso. Lo hice para Undici, uno de los patrocinadores de Node.js. Y eso, ¿cómo puedo decirlo?, es dramático.

Bien, déjame explicar el problema. Cuando realizas ese tipo de enfoque, toda la conexión HTTP es, toda la conexión, todo el servidor, todos los datos que quieres enviar al servidor, se enviarán primero al servidor PROC en la otra conexión HTTP sin TLS. Entonces, cuando no hay TLS, significa que cualquiera en tu red, en tu red local, podrá espiar la red y leer todo el tráfico sin ningún cifrado, independientemente de si tu servidor solicitado es HTTPS o no. Y eso es muy malo, porque en ese caso, por ejemplo, en el caso de la UNDG. Estaba utilizando el agente PROXY, ¿ok? Y cada vez que envías una solicitud a XSample.com utilizando la URL del PROXY como localhost HTTP, es como una dirección predeterminada para AmandaMiddleProx o HTTP2Kit, si alguien entra en tu red y espía usando Wireshark, por ejemplo, como puedes ver en la línea azul, está mostrando mi usuario y mi contraseña en la red, aunque XSample.com es un servidor final TLS. Eso es malo. Por eso entra en juego la tunelización de PROXY HTTP. Básicamente creas un túnel PROXY SSL entre el PROXY y el servidor. Así que significa que el PROXY no podrá leer tus datos. Solo creará el túnel para ti entre el servidor y el PROXY. Así que ese es el enfoque más seguro.

Así que sé que la mayoría de vosotros no pasaréis por algo relacionado porque no creo que los entrevistadores os pidan hacer eso. Así que asegúrate de usar una buena biblioteca de cliente HTTP. Onduchi ahora es seguro. Entonces, ¿qué aprendemos de todo esto? El objetivo a menudo eres tú. Y Node.js 20 viene con una característica emocionante llamada modelo de permisos, guión, guión permiso experimental. Solo un ejemplo final. Supongamos que hay un humilde desarrollador tratando de resolver un problema. Va al tutorial, encuentra un paquete solucionador de problemas. El paquete solucionador de problemas se ve así. Estaba tratando de leer el etc.passwd que es básicamente el archivo de contraseñas. Pero este humilde desarrollador decide ser cauteloso y usar el permiso experimental para permitir solo lectura en los archivos que quiere. Y entonces el humilde desarrollador se salvó gracias al modelo de permisos, porque estaba tratando de acceder al etc.passwd y se le negó porque este permiso no fue otorgado explícitamente al proceso.

Esta es una buena característica, por favor háganla uso de ella. Es experimental, por lo que podrían esperar algunos errores por ahora. No la utilicen en producción hasta que se estabilice, considerando que es una característica de seguridad. Así que hay muchas otras banderas como AllowRead, Write, Child Process, Worker, y muchas cosas.

Y bien, eso es todo por mi parte. Un poco sobre NearForm. NearForm es una empresa de servicios profesionales. Estamos distribuidos en todo el mundo. Tenemos una contribución fundamental a Node.js. Soy miembro del Node.js TSE, pero también tenemos a otras dos personas en el equipo central de Node.js también. Así que ciertamente podemos ayudar a su negocio a escalar bajo la infraestructura de Node.js. Independientemente, seguridad, rendimiento, cubrimos muchas cosas.

Y eso es todo por mi parte. Gracias a todos.