Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?

Hola y bienvenidos. Gracias por venir a mi charla. Es una jungla ahí fuera. ¿Qué está pasando dentro de tu carpeta modules? Mi nombre es Firas, y soy un mantenedor de código abierto. Empecé WebTorrent y StandardJS. He estado haciendo código abierto desde 2014. En el pasado, fui voluntario en la junta directiva de Node.js, y también enseño una clase sobre seguridad web en la Universidad de Stanford. Ahora soy el fundador de una startup llamada Socket, que ayuda a proteger el ecosistema de código abierto. Antes de empezar, permíteme contarte una historia. El 13 de enero de 2012, hace más de 10 años, un desarrollador llamado Faizal Salman publicó un nuevo proyecto en GitHub. Se llamaba UAParserJS, y analizaba las cadenas de agentes de usuario. Mucha gente encontró útil este proyecto. Y así, durante los siguientes 10 años, Faizal continuó desarrollando el paquete, con la ayuda de muchos contribuyentes de código abierto. Publicó 54 versiones, a medida que el paquete crecía en popularidad. Eventualmente llegó a 7 millones de descargas por semana. Finalmente fue utilizado por casi 3 millones de repositorios de GitHub. Ahora, permíteme contarte una historia diferente. El 5 de octubre de 2021, en un notorio foro de hackers rusos, apareció esta publicación. Un hacker ofrecía vender la contraseña de una cuenta de NPM que controlaba un paquete con más de 7 millones de descargas semanales. Su precio de venta era de $20,000 por esta contraseña. Ahora, aquí es donde las dos historias se cruzan. Dos semanas después, uaparser.js fue comprometido, y se publicaron tres versiones maliciosas. Se añadió malware a estos paquetes que se ejecutaría inmediatamente cada vez que alguien instalara una de las versiones comprometidas. Así que, ahora echemos un vistazo a lo que hace ese malware. Este es el archivo JSON del paquete para la versión comprometida. Y verás que utiliza un script de preinstalación. Esto significa que ese comando se ejecutará automáticamente cada vez que se instale este paquete. Así que, ahora veamos qué hace ese script. Lo primero que verás es que se divide en función del sistema operativo del objetivo. En Mac, no pasa nada, lo cual es una suerte para los usuarios de Mac, pero

Ahora, ¿qué hace este archivo DLL adicional? Bueno, roba contraseñas de más de 100 programas diferentes en la máquina Windows, así como todas las contraseñas en el administrador de credenciales de Windows. Así que, vaya, este es un malware realmente desagradable. Y, sabes, cualquiera lo suficientemente desafortunado como para ejecutar esto perdió todas sus contraseñas y tuvo que hacer, sabes, una especie de reinicio completo de sus cuentas en línea. No es un momento divertido. Así que, este es el resultado. Así que, este paquete se publicó durante unas cuatro horas. Y la comunidad de código abierto fue bastante diligente y lo reportó, y el mantenedor también fue bastante diligente. Y así que, sabes, cualquiera que lo instalara durante la ventana de cuatro horas fue comprometido, pero fue eliminado relativamente rápido. Cualquier compilación de software realizada en proyectos sin usar un archivo de bloqueo fue comprometida. Y cualquiera que tuviera la mala suerte de actualizar a esta nueva versión del paquete o tal vez quien fusionó un PR de bot para actualizar a esta nueva versión durante este tiempo habría sido también comprometido. Así que, esto fue una gran noticia en el mundo de JavaScript, y supongo que ya habrás oído hablar de este ataque. Pero esto es realmente solo la punta del iceberg. Así que, hemos estado rastreando paquetes que se eliminan de NPM por razones de seguridad, y hemos visto más de 700 paquetes eliminados por razones de seguridad en los últimos 30 días. Y creo que esta tendencia se está acelerando a medida que los atacantes se aprovechan del ecosistema abierto y la confianza que los mantenedores tienen entre sí y las políticas de contribución liberales que todos hemos adoptado en la era moderna del código abierto. Así que, creo que 2022 será el año de la seguridad de la cadena de suministro, ya que la conciencia de este problema está llegando a primer plano. Así que, una pregunta que podrías hacerte es, ¿por qué está ocurriendo esto ahora? Quiero empezar señalando que lo que estamos intentando hacer aquí es algo loco. Estamos intentando descargar código de Internet, escrito por individuos desconocidos que no hemos leído, que ejecutamos con todos los permisos en nuestros portátiles y servidores, donde guardamos nuestros datos más importantes. Así que, esto es lo que hacemos todos los días cuando usamos NPM install. Y solo tengo que decir realmente rápido que personalmente creo que es un milagro que el sistema funcione. Y que ha continuado

La cuestión es que puede llevar semanas o meses descubrir, reportar y detectar una CVE o vulnerabilidad conocida con las herramientas. Y por lo tanto, simplemente no es lo suficientemente rápido. Por lo tanto, puede valer la pena tomar un minuto aquí para distinguir rápidamente entre vulnerabilities conocidas y malware porque son muy diferentes. Las vulnerabilities son introducidas accidentalmente por los mantenedores, por los buenos, y tienen diferentes niveles de riesgo. Así que, a veces está bien enviar intencionalmente una vulnerabilidad conocida a producción si su impacto es bajo. Incluso si tienes vulnerabilities en producción, es posible que no sean descubiertas o explotadas antes de que actualices a una versión corregida, por lo que generalmente tienes algo de tiempo para abordar este tipo de problemas.

Ahora bien, el malware, por otro lado, es bastante diferente. El malware es introducido intencionalmente en un paquete por un atacante, casi nunca el mantenedor, y siempre terminará mal si envías malware a producción. No tienes unos días o semanas para mitigar el problema. Realmente necesitas detectarlo antes de instalarlo en tu portátil o en un servidor de producción. Pero en la cultura actual de desarrollo rápido, una dependencia maliciosa puede ser actualizada y fusionada en un tiempo muy corto. Y por lo tanto, desafortunadamente, esto conduce a un mayor riesgo de ataques a la cadena de suministro, porque cuanto más rápido actualices tus dependencias, menos ojos habrán tenido la oportunidad de mirar el code. Y por lo tanto, realmente creo que necesitamos un nuevo enfoque para detectar y bloquear dependencias maliciosas. Pero antes de entrar en eso, profundicemos un poco más en cómo funciona realmente un ataque a la cadena de suministro y su mecánica.

Así que, descargamos todos los paquetes de NPM, y pasamos unas semanas investigando. La descarga fue de 100 gigabytes de metadatos y 15 terabytes de tarballs de paquetes. Y mientras investigábamos estos metadatos y todos estos paquetes, notamos algunas tendencias en los tipos de ataques que vimos. Así que, voy a repasar estos ataques. Estos son los que encontramos. Así que, hay vectores de ataque, que es más o menos cómo el atacante te engaña y te hace ejecutar su code en primer lugar. Y luego, hay tácticas, que son lo que el code de ataque hace realmente o las técnicas que el atacante usa para ocultar su code. Así que, hablemos de los vectores de ataque. El primer vector de ataque y el más común es el typo squatting. El typo squatting es cuando un atacante publica un paquete que tiene un nombre muy similar a un paquete legítimo y popular. Y así, puedes ver aquí, hay dos paquetes aquí con nombres muy similares y uno de estos es malware y uno de estos es el paquete real, pero supongo que sería difícil para ti saber eso sin abrir realmente estos paquetes para ver qué hay dentro.

Entonces, abramos el paquete de malware y veamos qué está haciendo. Como puedes ver aquí, de nuevo, está utilizando un script de instalación, que es una técnica muy común que utiliza el malware. Y si abres este script de instalación para mirar el code, encontrarás que el archivo está fuertemente ofuscado. Pero puedo decirte, incluso sin saber exactamente qué está haciendo este code, puedes apostar que esto no es algo que quieras ejecutar en tu máquina. El siguiente vector de ataque que vimos se llama confusión de dependencia. Entonces, esto está bastante relacionado con el typosquatting. La confusión de dependencia ocurre cuando una empresa publica paquetes en un registro interno de NPM y utiliza un nombre que aún no ha sido tomado en el registro público de NPM. Entonces, más tarde un atacante puede venir y registrar un paquete con el mismo nombre que la versión pública y confundir las herramientas internas, de modo que las herramientas internas instalarán accidentalmente la versión pública. Por eso se llama ataque de confusión de dependencia. Entonces, mirando a través de los paquetes de NPM recientemente eliminados, pudimos encontrar un montón de ataques de confusión de dependencia probables, y la mayoría de estos paquetes tenían código malicioso en ellos. Entonces, todos estos paquetes tienen nombres que parecen entrar en conflicto con los nombres de paquetes internos de la empresa. Puedes ver aquí un montón de diferentes organizaciones, incluyendo gobiernos, que fueron afectados por esto. Y aquí hay un montón más, claramente apuntando a estas empresas específicas aquí

Bien, ahora hablemos de cómo puedes proteger tu aplicación. Nos hicimos esta pregunta cuando estábamos trabajando en... Mi empresa estaba trabajando en un producto llamado Wormhole, que te permite compartir archivos con cifrado de extremo a extremo. Y nuestro objetivo era intentar construir la forma más segura y privada de enviar archivos. Así que hicimos todas las cosas de security que se nos ocurrieron. Pensamos en la security temprano en el proceso de design. Escribimos pruebas, hicimos cumplir las revisiones de code, y fuimos bastante reflexivos sobre las dependencias que elegimos usar. Pero, ya sabes, todavía sentíamos que podíamos hacerlo mejor. Y entonces empezamos a pensar realmente en este problema y en lo que podríamos hacer para mejorarlo.

Entonces, la primera cosa que recomendaría es que simplemente intentes elegir mejores dependencias. Sabes, si envías code a producción, eres finalmente responsable de ello. Y, sabes, como industria, creo que necesitamos un cambio de mentalidad aquí porque la gente asume que pueden simplemente instalar cosas de internet y que van a ser seguras. Y no es necesariamente cierto. Y si estás enviando code a producción que incluye código abierto code, entonces realmente ese code es parte de tu aplicación. Y así tú eres finalmente responsable del comportamiento de ese code. Y, sabes, la licencia de código abierto más popular, la licencia MIT, literalmente dice esto en la licencia, dice que el código abierto code se proporciona tal como está sin garantía de ningún tipo y en ningún caso el autor será responsable de cualquier reclamación, daños o responsabilidad. Y así, sabes, mientras esto es legalmente cierto, la mayoría de las personas no piensan en su código abierto de esta manera. Y creo que realmente necesitamos un cambio de mentalidad. La otra cosa es que muy pocos de nosotros realmente leemos el code que estamos enviando a producción. Y así confiamos en otras heurísticas para ayudar a seleccionar dependencias. Entonces tal vez, sabes, miramos si el code hace el trabajo? ¿Tiene una licencia de código abierto? ¿Tiene buenos docs? ¿Tiene muchas descargas y estrellas de GitHub? ¿Tiene commits recientes? ¿Tiene tipos? ¿Y tiene pruebas? Y realmente no estamos abriendo el code para ir mucho más allá de esto. Entonces lo que eso significa es que no estamos conscientes de lo que el code puede estar haciendo. Y así, construimos una herramienta en Socket para ayudar con este problema. Así que puedes rápidamente echar un vistazo y tener una idea de la seguridad de un paquete. Y así es como se ve. Así que puedes ir a Socket y buscar paquetes para averiguar qué comportamiento tiene el paquete. Y así en este ejemplo aquí, puedes ver que este paquete contiene scripts de instalación. Y eso se destaca muy prominentemente en la página. Así que es lo primero que ves. Y este paquete también contiene binario, sabes, o código nativo code, lo que significa que no es fácil auditar el code. No es como un legible por humanos. Y así ambos de estos problemas son destacados. Y en este caso, no es necesariamente esto no es un ataque a la cadena de suministro por ningún medio. Pero es agradable que esto se destaque muy prominentemente para que puedas tomar una decisión informada si quieres usar este paquete o no. También puedes ver que tenemos muy útiles puntuaciones de calidad que aparecen en la parte superior de la página también. Ahora, echemos un vistazo a otro ejemplo. Así que este paquete aquí, Angular Calendar, es un paquete bastante útil. Es un componente de calendario que aparece en la página y muestra un pequeño calendario. Pero si profundizas en sus dependencias, en realidad encontrarás que algunas de sus dependencias están haciendo cosas bastante invasivas

Otra idea es auditar cada dependencia. Así que, sabes, si estás construyendo una aplicación verdaderamente crítica para la seguridad, como lo estábamos haciendo con wormhole, entonces, sabes, una opción es literalmente leer cada línea de code de tus dependencias. Así que si, de nuevo, ponemos esto en, en un eje de comenzar desde una auditoría completa por un lado, leyendo cada línea de code hasta YOLOing por el otro lado, y, sabes, por YOLOing, me refiero a, ¿como hacer nada? ¿Qué tan de cerca deberías auditar tus dependencias? Y lo que ves aquí es que estamos en la misma situación. Tenemos compromisos y realmente no hay buenas, no hay buenas soluciones. Así que hacer una auditoría completa es algo que sólo las empresas más grandes y ricas parecen hacer en la práctica. Es mucho trabajo. Normalmente necesitas tener un equipo de seguridad mirando cada uno de estos paquetes, y también tenemos que aprobarlos uno a uno y añadirlos a una lista de permitidos, lo cual es realmente lento. Y esto es caro sólo por el tiempo y el esfuerzo que requiere. Por otro lado, no hacer nada y simplemente instalar lo que quieras sin, incluso mirar el code, tiene sus desventajas. Así que significa que eres vulnerable a la cadena de suministro

Y un poco relacionado. Entonces, no recuerdo el nombre del paquete, pero había un paquete realmente popular, y hace un mes o dos, el autor lo retiró de GitHub y dijo, liberar a Aaron Swartz, algo así. ¿Recuerdas de lo que estoy hablando? Entonces sí, esto también será detectado porque tienes un cambio significativo en el code ¿verdad? Así que también detectará esos problemas. Sí. No es suficiente, este es un ejemplo perfecto en realidad, donde muchas de las estrategias que otras empresas y otros equipos que están tratando de resolver este problema están tomando no habrían realmente detectado este problema porque aquí es donde tienes a un mantenedor ellos mismos agregando malware o mal code a su propio paquete. Y entonces confiar en cosas como la firma de code, por ejemplo, no habría hecho realmente nada en este caso porque el propio mantenedor habría tenido las llaves para firmar su code. O si estás mirando una base de datos de vulnerabilidades database, esto no va a estar en una base de datos de vulnerabilidades. Y entonces, lo siento, estoy recibiendo una llamada telefónica ahora mismo. Sí. Entonces de todos modos, creo que ese incidente fue realmente muy ilustrativo de los desafíos con los otros enfoques y por qué realmente lo que quieres hacer es entrar en el code real y mirar lo que está haciendo. Sí. Solía trabajar en una empresa de tecnología médica. Y entonces siempre era el escenario si haces una actualización, entonces realmente tendrías que leer todo el code que era nuevo. Y sí, así que traté de evitar cualquier dependencia porque bueno, es demasiado trabajo leer todo lo que es nuevo en todas tus dependencias.

Sí. Bueno, en realidad, security, si lo piensas, debería ser después quizás accessibility. No, tal vez incluso antes de accessibility. Es lo más importante. Es más importante que tus elegantes configuraciones de línea de comandos. Es más importante que tus animations de 60 FPS. Es lo más importante. Sí, eso también es una respuesta, creo. Bueno, se nos acabó el tiempo para preguntas y respuestas, pero Feroz va a estar en una sala de conferencias en el chat espacial. Así que, puedes hacer clic en el enlace en la línea de tiempo de abajo. Feroz, muchas gracias por asustarnos y entretenernos. Ha sido un placer tenerte. Sí, gracias Mateen. Aprecio las buenas preguntas y ha sido un honor estar aquí. Así que, muchas gracias. Lo aprecio. Bien, adiós. Adiós.