Securing NPM Packages

Hola a todos. Estoy aquí para mostrarte cómo ejecuto malware directamente desde NPM en mi máquina para que tú no tengas que hacerlo. Bueno, esa no es toda la historia, pero no nos adelantemos. ¿Verdad?

Bien. Entonces, ¿quién soy? Hola. Soy Zebe. Si escribes nauter en cualquier cuadro de texto en línea y obtienes algún resultado, probablemente será sobre mí. Me interesa JavaScript. He estado trabajando con Node y JavaScript durante muchos años. Y hace unos años cambié mi enfoque más hacia la seguridad. Ahora estoy trabajando en Labemote, que es el logo en el medio que está protegiendo Metamask, que es el lindo zorro. Y también estoy dirigiendo un grupo de Meetup y conferencias llamado MeetJS.

Bien. Pero esta presentación va a ser una toma bastante caótica sobre algunas cosas de seguridad que quizás no conozcas aún. Y me gusta compararla con la charla TED de Clifford Stahl. Si no la has visto, te la recomiendo. Clifford Stahl es el primer respondedor de incidentes en seguridad, en seguridad informática en general, antes de que se llamara seguridad informática y respuesta a incidentes. Una historia muy interesante. De todos modos, me desvío.

Así que, permíteme comenzar con mi pregunta favorita. ¿Tomarías una cadena de mí y sin leerla, la pondrías en tu código fuente que luego compilas y envías a producción en tu aplicación web? Ya sea del lado del servidor, del lado del cliente, lo que sea. ¿Lo harías? Bien. Ahora, ¿te ayudaría a convencerte de hacerlo si la pongo en un archivo tar.gz? Bueno, eso es exactamente lo que son los paquetes de NPM. Y no me malinterpretes, son gloriosos. Los amamos. Pero al mismo tiempo, son solo entrada no sanitizada de personas aleatorias en línea que pones en tu aplicación y ejecutas en producción sin leer, ¿verdad? Así que sí, sería genial consumir paquetes de NPM de la manera en que lo hacemos. Me gusta consumir paquetes de NPM, pero ¿y si algunos de ellos no son geniales, verdad? Y no me refiero a paquetes mediocres. He publicado una buena cantidad de paquetes mediocres y no pasó nada malo. Pero me refiero a paquetes maliciosos.

No voy a hacer un resumen de noticias sobre paquetes maliciosos. Ya has visto todo eso.

Bien. Entonces, ¿cómo llegué aquí? Bueno, estuve interesado en la seguridad de la cadena de suministro por un tiempo. Comencé donde todos comienzan, dependencias vulnerables, escaneando dependencias vulnerables, y luego notando que es demasiado tedioso responder a todo eso. Así que necesito una forma estructurada de ignorarlas y demás. Y así fue como se creó NPM Audit Resolver. Luego cambié mi enfoque a los scripts de instalación maliciosos. Y hay un montón de herramientas que exploré y un montón de trucos que puedes ver en mis presentaciones anteriores. Y luego me centré en defenderme de paquetes maliciosos que realmente se convierten en parte de la aplicación después de que todas las defensas anteriores ya fallaron. Y de esto vamos a hablar hoy. Otra versión de eso.

Y también hubo una masterclass de codificación defensiva a la que posiblemente puedas asistir en alguna otra ocasión en el futuro. Y esas charlas y todo están disponibles en mi sitio web. Pero te prometí que iba a ejecutar malware, ¿verdad? Así que centrémonos en eso. Entonces primero, ¿dónde conseguimos malware? Si quieres obtener malware, rara vez puedes descargar este malware directamente desde NPM a sabiendas, porque antes de que supieras que el paquete era malicioso, NPM probablemente ya lo eliminó. Así que si quieres explorar un paquete malicioso, puedes ir a Socket Dev, donde tienen un explorador de contenido de paquetes en el sitio web. Y no eliminan versiones antiguas. Así que puedes mirar el contenido del paquete y descargar partes, que es lo que hice. Vale la pena mencionar, el paquete en cuestión estaba ofuscado. Y la historia es, intenté ofuscarlo manualmente, porque encuentro cosas raras divertidas. Pero tenía cuatro capas de ofuscación y todo. En algún momento, simplemente pensé, estoy trabajando en algo que puede proteger mi código en tiempo de ejecución. ¿Por qué no uso eso en lugar de ofuscar el código? Y eso es lo que hice.

Así que ahora, pasemos a verme ejecutar malware real, ¿de acuerdo? Voy a omitir la configuración. Este es mi laboratorio. Es un proyecto experimental de juguete. Y aquí en el lado izquierdo, puedes ver que el archivo de malware no es muy legible. Y es bastante largo, como ves en la miniatura. Y ahora si ejecuto LavaLab, solo un terminal, lo ejecuto en la muestra de malware de LoffyGang.

Esto es solo JavaScript, ¿verdad? Lo que ves a la izquierda. Ejecutando esto. Solo comprobando si estoy seguro. Y luego, obviamente es una demo, así que voy a hacer trampa. Este es un historial de lo que ejecuto. Y lo que estamos haciendo ahora es pasar por la evaluación de lo que desempaqueta y convierte este lío que ves a la izquierda en algo que realmente se puede ejecutar como JavaScript. Así que necesitamos permitirlo mediante prueba y error. Necesitamos permitirle algunas llamadas a eval para que realmente empiece a funcionar. Y luego, después de algunos eval, regex y parsint, el código realmente comienza a hacer cosas.

Así que este es un malware dedicado a ejecutarse en Node.js. Eso es lo que aprendimos al ver requirefs, ¿de acuerdo? También requiere HTTPS. No vamos a dejar que requiera las cosas reales. Así que lo que ves arriba es una lista de cosas a las que estaba tratando de acceder. Y luego estoy tomando decisiones aquí sincrónicamente mientras el programa está en pausa, si quiero darle esa referencia o no. ¿No es divertido? Así que le negamos el acceso a todo lo que quiere requerir y en su lugar le damos falsos.

Y ahora se nos pregunta qué deberíamos darle al programa como tipo process.exec, ¿de acuerdo? Así que vamos a darle una función falsa. Ahora requiere algunas cosas más y alcanza el proceso. Eso es bastante común. Otro proxy. De acuerdo. Process.env. Sí, eso fue fácil de predecir. De acuerdo. Y ahora podemos ver que está leyendo la variable de datos de la aplicación local. Así es como aprendemos que este es un malware de Windows, ¿de acuerdo? Y estamos devolviendo una cadena que será fácil de reconocer en otros lugares en lugar del valor real. Y luego vemos que intenta leer el directorio y pasa esa cadena reconocible a read your sink. De acuerdo. Estamos aprendiendo cómo funciona sin nunca desofuscar el paquete, ¿verdad? Así que ahora itera sobre las carpetas y recopila alguna información. Luego, otra indicación de que este es un malware de Windows, ejecuta task list. Genial.

Y luego publica en un webhook de Discord para que los adolescentes que realmente escribieron ese malware puedan recopilar los datos que capturaron en su plataforma en línea favorita sin tener que configurar ninguna infraestructura de servidor. ¿No es conveniente? Y eso es lo que hace el malware. Divertido, ¿verdad?

Bien. Entonces, ¿por qué detenerse en la ofuscación? ¿Sabías que algún malware puede entregarse como bytecode precompilado? El código en pantalla te muestra cómo. El script de VM en Node.js no verifica realmente si el código que estamos tratando de compilar coincide específicamente con la caché. Solo verifica si la longitud del código parece coincidir con los bytes en caché del bytecode, lo que facilita entregar una carga útil de bytecode sin tener que entregar el código legible para eso. Bien. Así que, sí. Puedo... Nota al margen, no publiques malware en NPM incluso si tienes buenas razones y estás haciendo white hat y todo eso.

Pero antes de llegar allí, echemos un vistazo a otro pequeño ejemplo de algún código que luego compilé. Y ahora puedo ejecutarlo con Lava Lab C, que es un Lava Lab que puede manejar bytecode compilado. Así que la plataforma tiene que coincidir y todo, por lo que no es tan fácil obtener bytecode compilado de alguien y ejecutarlo en tu plataforma. Pero podemos ver que realmente funciona desde el archivo compilado. Este es bytecode de JavaScript, y me va a preguntar si quiero darle console. Como puedes ver, esto coincide con el código a la izquierda. Y luego está accediendo a URL. Y hay algunos artefactos de la propia compilación, por lo que hay un mapeo interno. Eso es interesante, ¿verdad?

Y luego se accede a require. Ejecutamos read file sync en una carga útil. Devolvemos un falso, y luego eval es una función. Y ahora la carga útil que devolvimos se convierte en JSON, aunque no es visible en el código. Pero esa es la operación a la que se compiló este código, curiosamente. ¿Divertido, no? Y luego ejecutamos el resultado de eso, al que le di un objeto con un proxy para ver si hay otros métodos siendo llamados en él. Y eso es todo. Así que eval de algo vacío no hizo mucho. Bien, pero esto también funciona en bytecode compilado. Pasando a las defensas, porque en realidad estoy del lado de la defensa. Así que no vamos a hablar sobre las defensas que se basan en información existente sobre paquetes. Así que hay npm audit que va a verificar si tus dependencias tienen problemas conocidos y te lo hará saber.

Y eso es dos meses después de que esa dependencia existiera que algunos humanos pasaron por el proceso de informar sobre ello. Hay socket que puede hacerlo en cuestión de horas con algunas heurísticas, pero luego tienes que verificar si las advertencias son correctas. Lo que buscamos es que después de que hayas ignorado o no hayas aplicado todas esas protecciones, y el código malicioso ya esté en tu aplicación ejecutándose en producción, queremos detener eso.

Y como viste, puedo hacerlo, ¿verdad? Si podemos controlar el código malicioso en tiempo de ejecución, usemos la tecnología detrás de ello para hacer nuestras aplicaciones más seguras. Y ahí es donde entra Hardin JavaScript. Puedes ir a hardenjs.org y ver un hermoso video sobre ello donde mi mago de código abierto favorito está explicando lo que está sucediendo. En resumen, JavaScript resulta estar bien diseñado para la seguridad. Es una declaración inesperada, sí. Mira cómo se está estandarizando. Hay ECMA que trabaja en el lenguaje en sí, que apenas tiene APIs poderosas en él. Y luego cada API poderosa proviene ya sea del navegador o de node o de cualquier entorno host en el que estés ejecutando. Así que eso se estandariza en otro lugar. Así que toma la Ley de Conway que dice que la infraestructura de comunicación de las personas que construyen software va a dar forma al software en sí. Terminamos con una muy buena separación entre el lenguaje en sí y las APIs poderosas. El poder solo es alcanzable a través del alcance. Puedes alcanzar un global o requerir/importar algo. Y Hardin JavaScript está ahí para controlar el alcance y los mecanismos de importación. Y eso ya está implementado como SESS-SHIM. Así que podemos usarlo mientras esperamos que se estandarice. Sí, hay un proceso en marcha para eventualmente incluirlo en el estándar de JavaScript. Así que Hardin JavaScript proporciona dos cosas que vale la pena explicar aquí.

Una es el compartimento, que ofrece un aislamiento de alcance que podemos aplicar a cualquier código. La otra es el bloqueo que previene cualquier tipo de contaminación de prototipos y refuerza los intrínsecos de JavaScript en sí mismos. Así que cualquier cosa global en JavaScript, como el prototipo de objeto y el prototipo de array, no puedes romper más. Así que este es el bloqueo muy simple. El bloqueo real es como 5,000 líneas de código o así. Y eso es lo que usamos detrás de escena en Lavamote. Así que Lavamote es la herramienta en la que estoy trabajando que toma Hardin JavaScript y lo aplica en tu stack tecnológico para hacer tu tiempo de ejecución más seguro de paquetes maliciosos. Y lo aplicamos específicamente a tus dependencias. Así que esta es una herramienta de seguridad de la cadena de suministro que funciona en tiempo de ejecución.

¿Qué hace? Toma cada paquete y lo coloca en su propio compartimento. Así que todos los archivos de un paquete van a compartir un global, pero no van a compartir la referencia global con ningún otro paquete o el código de tu aplicación. ¿Suena imposible? Sí, a mí también me sonaba imposible. Se puede hacer. Y también controlamos la estructura de la dependencia y permitimos que las dependencias se llamen entre sí. Todo sucede en el mismo hilo, en la misma ventana, en cualquier plataforma que estés usando. Y también entregamos herramientas para ayudarte a crear una política para decidir qué paquete puede acceder a qué. Podría explicarlo y agitar mis manos aún más, pero prefiero mostrarte. Así que es hora de la demostración final.

Primero echemos un vistazo a las fuentes. Así que tenemos una pequeña aplicación tonta aquí que necesito más espacio para mostrar. Así que esta es una pequeña aplicación donde establecemos una cookie para que tengamos algo valioso que proteger. Y este console log es solo para documentar que está ahí. Y luego llamamos a algunas dependencias. Y una de nuestras dependencias es un paquete llamado CookieMonster, que noto que no publiqué en NPM porque es un paquete malicioso. Y lo que está haciendo el CookieMonster es, sí, nos está dando una cita aleatoria de CookieMonster. Encantador. Pero también está robando nuestras cookies. Bueno, ¿qué esperabas? Es CookieMonster. Y ahora tenemos una construcción de Webpack que puede construir esta aplicación de dos maneras. Una es la construcción de Webpack más usual que puedas imaginar. La otra es la misma pero extendida con un plugin de Lafamote. Este es un plugin que actualmente está en beta. Para cuando lo escuches, podría ya estar en la versión 1.0. Definitivamente estamos lanzando la versión 1.0 antes de que termine el año en curso.

Y ahora App.js se construye y podemos ejecutarlo en el navegador. Así que echemos un vistazo a esta aplicación ejecutándose en el navegador. Así que esta es la construcción donde no se aplicó Lafamote. Así que lo que está sucediendo en la consola, si echas un vistazo, está el console log que dice localhost es nuestro dominio y name equals chocolate chip es nuestra cookie. Y luego obtenemos una cita de CookieMonster, la respuesta del archivo TypeScript que está ahí para probar que Webpack está haciendo lo suyo.

Y luego obtenemos errores al intentar enviar la cookie robada a example.com. Porque el origen cruzado lo impidió, pero es una cuestión de configuración del servidor, ¿verdad? Pero CookieMonster tenía acceso a nuestras cookies y a nuestro fetch y todo, lo cual no me gusta realmente. No quiero eso.

Así que aquí, puedes ver que en la misma situación con Lafamote aplicado, estamos recibiendo un error que dice que fetch no es una función. ¿Cómo sucedió eso? Te lo voy a mostrar. Así que tenemos una carpeta de Lafamote aquí donde hemos generado una política que dice que estas son las cosas que el paquete parece estar usando. Esto es solo para que lo revises y permitas o no. Y luego tenemos un archivo de anulación de políticas que puedes crear manualmente y denegar todo si quieres. O denegarlo selectivamente. Así que si todavía tenemos tiempo, podría intentar permitir esto y volver a ejecutar la construcción. Obtiene... Obtiene... No. Bien. Bien. Volviendo a ejecutar la construcción y ahora podemos ver la misma aplicación pero con fetch permitido. Así que fetch está permitido pero el acceso al global document no está permitido. Así que mientras fetch funciona, envía undefined slash undefined porque estos valores globales no existen para nuestro paquete CookieMonster. ¿No es divertido?

Bien. Y con eso, quiero decirte que oferta por tiempo limitado, puedo ayudar a algunas personas a configurar su proyecto con Lafamote. Hay un montón de herramientas allí. Pero deberías comenzar con allowscripts que es una pequeña cosa que puedes configurar en cinco minutos y prevenir la mayoría de los ataques de paquetes maliciosos que conocemos. Y sí, hay más en Lafamote. Puedes leer sobre ello y explorar todas las herramientas y características.