5 Formas en las que podrías haber hackeado Node.js

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

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

Entonces, en primer lugar, presentaré el 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 selección de Node.js. Está compuesto por el Comité Técnico de Dirección de Node.js, contribuyentes específicos de Node.js con experiencia en seguridad, el equipo de lanzamiento de Node.js y el equipo de compilación, ¿de acuerdo? 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 es solo una de ellas. Así que puedes formar parte de él. Solo envíame un mensaje, envíame un mensaje, puedes ir al repositorio y podrás verlo, ¿de acuerdo?

Entonces vamos a lo que importa. ¿Encontraste una posible vulnerabilidad de seguridad? Por favor, no abras un problema público. Estarás revelando la vulnerabilidad y eso es crucial. Eso es muy malo para los mantenedores, porque necesitamos apurarnos. Necesitamos hacer muchas cosas en un corto período de tiempo y eventualmente es muy malo, en realidad. Por lo general, consulta el archivo security.md en el archivo Node.js, podrás verlo. Si vas a HackerOne, también podrás verlo. Entonces, el proceso de envío de vulnerabilidades de Node.js es bastante sencillo, ¿de acuerdo? Encuentras una posible vulnerabilidad y vas a HackerOne. HackerOne es una plataforma donde puedes enviar cualquier posible vulnerabilidad y la evaluamos. Y luego completas el formulario y el equipo de selección de Node.js recibe tu informe. Y lo evaluamos según nuestro modelo de amenazas.

Y si eso es aceptado, prepararemos una solución de seguridad y un lanzamiento de seguridad. ¿De acuerdo? Así que, bueno, puedes ganar dinero a través de programas de reducción de errores. ¿De acuerdo?

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

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

Tomemos este ejemplo, ¿de acuerdo? Estás en Windows. Nuevamente, lo siento, usuarios de Windows. Luego, digamos que instalas cualquier tipo de juego. La mayoría de los juegos hoy en día necesitan abrir SSL. Así que tienes SSL abierto 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 archivo 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, este paquete requiere crypto, en realidad, al principio. Cada vez que requieres crypto, el módulo HTTPS o TLS en Node.js, inicializará OpenSSL. Y cuando se inicializa, buscará providers.dll en el directorio de trabajo actual. Y por ejemplo, si el paquete, el paquete malicioso, contiene solo un script post-install que llama a las versiones de NPM que, en el fondo, requieren crypto, inicializará OpenSSL y cargará providers.dll y luego ocurre el ataque. Ahora piensa que ya no carga providers.dll en el directorio de trabajo actual.

Entonces, pasemos al segundo. Hablemos sobre el ataque de DNS rebinding. Cuando quieres visitar un sitio web como xample.com o jsnation.com, tu computadora necesita conocer la dirección IP de ese sitio web. El DNS es como una guía telefónica para Internet que ayuda a tu computadora a encontrar la dirección IP correcta en el DNS.

Imagina que alguien quiere engañarte para que visites un sitio web malicioso en lugar del que tenías la intención de visitar. Podrían utilizar algo llamado ataque de DNS rebinding para hacer esto. Supongamos que hay un usuario que utiliza node-inspect. Esto abrirá el depurador de Node.js. Luego, accedes a attacker.com y attacker.com te redirige a una dirección IP inválida. Node.js no estaba validando correctamente esa dirección IP. Luego, va al navegador y el navegador dice: `OK, esta no es una dirección IP real, preguntaré al servidor DNS`. El servidor DNS se dirige a un servidor DNS con una conexión comprometida, lo que significa que quiere el DNS o la dirección IP para el 10.0.2.555 en el puerto 9229. Y luego, podrías pensar: `Bueno, el atacante necesitaría acceder al servidor DNS y eso es difícil, en realidad no`. El DNS no está protegido por SSL o TLS. Entonces, si estás en la misma red, simplemente puede realizar un ataque de intermediario.

Entonces, bien. Supongamos que el atacante ahora tiene acceso al servidor DNS. Y luego, cuando solicitas la dirección IP de esa dirección IP inválida, mapea la solicitud a su dirección IP con un tiempo de vida corto. ¿De acuerdo? Y luego, la página intenta cargar un slash JSON. El tiempo de vida es básicamente un número especial que se utiliza para asegurarse de que los mensajes enviados a través de Internet no queden atrapados en un bucle o sigan yendo para siempre. Funciona como un temporizador que le indica a la computadora encargada de enviar el mensaje cuándo detenerse y tratar de entregarlo si lleva demasiado tiempo. ¿De acuerdo? 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. ¿De acuerdo? Entonces, bien. Luego carga el SlashJSON bajo la IP de ataque y luego el tll expira. Y esta vez, requiere nuevamente al servidor DNS y el atacante lo envía al localhost.

Entonces, expondrá el SlashJSON bajo tu localhost a la IP del atacante, lo que significa que mostrará la URL del WebSocketDebugger, y luego el atacante obtendrá acceso a tu máquina. Bueno, puede ejecutar lo que quieras, o ella quiera, en tu instancia comprometida de Node.js. Entonces eso es muy malo. Es difícil de replicar, ¿de acuerdo? Pero sigue siendo un buen ataque. Después de resolver esto, recibimos otro informe de que, bueno, se solucionó el DNS rebinding, pero hay un caso especial en Apple, y luego lo solucionamos nuevamente. Sucede. Entonces sí. El tercero es el contrabando de solicitudes 80PS. Entonces 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 una soda. Y quieren hacerlo de manera astuta. Entonces tú no ves. Escriben una nota con el pedido de la soda y la esconden dentro de tu pedido de hamburguesa, como un mensaje secreto, ¿de acuerdo? Entonces el camarero toma tu pedido de hamburguesa y ve la nota para la soda escondida dentro. Pero debido a que 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 una soda, aunque solo pediste una hamburguesa, ¿de acuerdo? Hagámoslo. Hagámoslo de manera técnica ahora, ¿de acuerdo? Supongamos que simplemente haces una solicitud y luego tienes una CDN. Y luego tienes una red privada debajo, digamos que tengo un microservicio llamado usuarios, ¿de acuerdo? Y luego puedes tener, no sé, varios servidores. Tienes un equilibrador de carga, un proxy inverso. Realmente no importa. Y para que esto suceda en la vulnerabilidad de Node.js, básicamente, la codificación de transferencia era un encabezado necesario para explotarlo. Entonces, básicamente, la codificación de transferencia es un encabezado que sirve para decirle al servidor cómo interpretar los bytes en la solicitud del encabezado, ¿de acuerdo?, en el cuerpo del encabezado también. Entonces imagina que hay un usuario malicioso que envía una solicitud con el siguiente contenido, publicar hoy slash. Y luego uno de los encabezados es el X punto y coma slash n. Esa es la nueva línea. Esto estaba pasando por alto la validación de Node.js LLTP. Entonces, Node.js esperaba un CLLF, que es retorno de carro y avance de línea, para separar correctamente los encabezados. Pero se envía un encabezado no válido usando solo LF, el slash n.

Pero aún está siendo procesado por Node.js, ¿de acuerdo? Entonces, ¿qué estaba sucediendo detrás de escena? Esta solicitud va a la CDN, la 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 administración, aunque solo envié una solicitud.

Entonces, tal vez las cosas de administración no estaban expuestas a la red, a la web, aunque podría hacer esta solicitud. Entonces eso es terrible, ¿de acuerdo?

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, ¿de acuerdo? Esto ocurre muy a menudo en las universidades, ¿de acuerdo? Supongamos que un usuario malicioso crea un archivo falso openSSL.cnf que contiene la configuración maliciosa. openSSL.cnf es solo un archivo que contiene la configuración de seguridad para openSSL, ¿de acuerdo? Entonces el atacante puede hacer muchas cosas, como modificar el generador de claves, alterar la configuración predeterminada, y más. Y luego el usuario malicioso crea este falso openSSL.cnf en esa ubicación específica, io.js build ws.out.release y así sucesivamente y va a ese archivo largo. Y luego Node.js en el inicio intentaba leer un archivo llamado openSSL.cnf en esa ubicación específica. Fue un error de nuestra parte. Entonces el atacante podría descubrirlo utilizando herramientas de utilidad de Linux como strace. Lo usó para rastrear las llamadas al sistema, ¿de acuerdo?, 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, hemos abordado esto, como dije, y he creado una prueba que aborda este problema. Entonces, si quieres ver el PR 46150, podrás ver cómo lo resolví.

Entonces, OK, una vez que Node.js lo carga, el atacante obtendrá acceso a ese openSSL con una configuración personalizada. Entonces el atacante ahora lo controla. 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 solucioné, pero fue difícil. Supongamos que haces una solicitud normal. Realizas una solicitud GET al servidor y la dirección IP del cliente es xsx porque es tu dirección IP. Pero luego quieres usar un servidor PROC. Es bastante común porque digamos 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 de intermediario. Hay otra herramienta llamada HTTP Toolkit Proxy. Puedes interceptar las solicitudes del depurador. Eso es muy útil para los desarrolladores. Este es solo un ejemplo del proxy de intermediario. Y luego supongamos que estás en una entrevista y el entrevistador te pide que implementes un cliente de proxy HTTP, ¿de acuerdo? Y terminas con el siguiente ejemplo.

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

De acuerdo, déjame explicarte 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 deseas enviar al servidor, se enviarán primero al servidor de PROC en otra conexión HTTP sin TLS. Entonces, cuando no hay TLS, significa que cualquier persona en tu red, en tu red local, podrá interceptar la red y leer todo el tráfico sin ningún cifrado, independientemente de si el servidor solicitado es HTTPS o no. Y eso es muy malo, porque en ese caso, por ejemplo, en ese caso de UNDG. Estaba usando el agente PROXY, ¿de acuerdo? Y cada vez que envías una solicitud a XSample.com utilizando la URL del PROXY como un HTTP de localhost, es como una dirección predeterminada para AmandaMiddleProx o HTTP2Kit, si alguien va a tu red y lo intercepta usando Wireshark, por ejemplo, como puedes ver en la línea azul, se muestra mi usuario y mi contraseña en la red, aunque XSample.com sea un servidor con cifrado TLS. Eso es malo. Por eso entra en juego el túnel HTTP PROXY. Básicamente, creas un túnel SSL de PROXY entre el PROXY y el servidor. Entonces, significa que el PROXY no podrá leer tus datos. Solo creará el túnel entre el servidor y el PROXY. Así que ese es el enfoque más seguro.

Sé que la mayoría de ustedes no se encontrarán con algo relacionado porque no creo que los entrevistadores les pidan que lo hagan. Así que asegúrate de utilizar una buena biblioteca de clientes HTTP. Onduchi es seguro ahora. Entonces, ¿qué aprendemos de todo esto? El objetivo eres tú en muchas ocasiones. Y Node.js 20 viene con una característica emocionante llamada modelo de permisos, guion, guion permiso experimental. Solo un ejemplo final. Supongamos que hay un desarrollador humilde tratando de resolver un problema. Va al tutorial, encuentra un paquete solucionador de problemas. El paquete solucionador de problemas se ve así. Estaba intentando leer el etc.passwd que básicamente es el archivo de contraseñas. Pero este desarrollador humilde decide ser cauteloso y utilizar el modelo de permisos experimental para permitir solo lectura en los archivos que desea. Y luego el desarrollador humilde se salva gracias al modelo de permisos, porque intentaba acceder al etc.passwd y se le denegó el acceso porque este permiso no se le otorgó explícitamente al proceso.

Esta es una buena característica, por favor úsala. Es experimental, así que puedes esperar algunos errores por ahora. No la uses en producción hasta que se estabilice, considerando que es una característica de seguridad. Así que hay muchos otros indicadores como AllowRead, Write, Child Process, Worker y muchas otras cosas.

Y bueno, eso es todo de mi parte. Un poco sobre NearForm. NearForm es una empresa de servicios profesionales. Estamos distribuidos en todo el mundo. Tenemos contribuciones principales a Node.js. Soy miembro del equipo principal de Node.js, pero también tenemos otros dos miembros en el equipo principal de Node.js. Así que definitivamente podemos ayudar a que tu negocio crezca bajo la infraestructura de Node.js. Independientemente, seguridad, rendimiento, muchas cosas que cubrimos.

Y eso es todo de mi parte. Gracias chicos.