00:00:00Esto es serio y no es broma, han sido un par de horas difíciles, porque ha habido
00:00:06un enorme ataque a la cadena de suministro en Axios, sí, ese Axios que tiene más de 80 millones de
00:00:14descargas semanales.
00:00:15Ahora, lo primero es lo primero.
00:00:18Para que compruebes si estás afectado, adjunto encontrarás un enlace a un artículo, y
00:00:23compartiré más detalles en un segundo, pero esto es importante, para que compruebes si
00:00:27has sido afectado, debes seguir ese enlace de abajo y ejecutar los comandos que verás allí
00:00:32para tu sistema operativo, Mac OS, Linux, Windows, todos están afectados.
00:00:37Debes ejecutar estos comandos si estás afectado.
00:00:40Y especialmente si estos pasos de aquí muestran que has sido comprometido, necesitarás
00:00:49rotar tus secretos, cambiar tus contraseñas, considera tus credenciales, las claves API en
00:00:55tu sistema, todo lo que esté en tu sistema, como robado.
00:01:00Considera tu contraseña robada, cámbialo todo, deshabilita las claves API, esto es muy importante.
00:01:07Ahora, ¿qué pasó exactamente?
00:01:09Axios, obviamente una librería de JavaScript muy popular, una librería que se puede usar para enviar peticiones HTTP
00:01:17desde, por ejemplo, una app de React a una API de backend.
00:01:22Se usa muchísimo, como puedes ver, y se ha inyectado código malicioso en
00:01:28esta librería.
00:01:29Ahora, esto no significa que los sitios web que usan esa librería hayan sido afectados.
00:01:36Significa, en cambio, que los sistemas donde instalaste esa librería, tu MacBook, tu
00:01:41PC, o quizás ese VPS donde construiste tu sitio web, esos han sido comprometidos.
00:01:50Si ejecutaste npm install, bun install, npm update, bun update, cualquier cosa similar en las últimas
00:01:57par de horas, hay un alto peligro de que hayas sido afectado.
00:02:00Nuevamente, compartí esas comprobaciones que deberías realizar para ver si has sido afectado.
00:02:05Ahora, ¿cómo ocurrió exactamente todo esto y qué es exactamente un ataque a la cadena de suministro?
00:02:10También compartiré, por cierto, cómo puedes protegerte contra ataques como este en el futuro.
00:02:15Pero primero, entendamos qué sucede exactamente y qué es un ataque a la cadena de suministro.
00:02:20Un ataque a la cadena de suministro es simplemente un ataque que no se dirige al código de tu aplicación.
00:02:24El atacante no intenta infiltrarse directamente en tu sistema o en tu base de código en su lugar.
00:02:31Aprovechan el hecho de que el código de tu aplicación suele tener dependencias, las cuales a su vez
00:02:37tienen dependencias.
00:02:38Así que tienes esa cadena de dependencias y el ataque se dirige a esta cadena.
00:02:45Por lo tanto, ocurre "aguas arriba" de tu código.
00:02:48Así que una de estas dependencias tiene algún código malicioso debido a un ataque donde ese código fue
00:02:54inyectado en ella, no porque el mantenedor esté intentando atacarte.
00:02:58Sino que, por ejemplo, como en este caso, la cuenta de un mantenedor se ve comprometida
00:03:03y el atacante la usa para inyectar código malicioso en alguna librería, en algún paquete,
00:03:10que otro paquete puede estar usando y tu código puede estar usando ese paquete que
00:03:16usa el paquete malicioso, o tal vez tu código de aplicación trae directamente la dependencia maliciosa.
00:03:23De cualquier manera, una de tus dependencias ahora viene de repente con código malicioso.
00:03:28Y en el momento en que ejecutas npm install o algo similar, o actualizas, ese paquete se
00:03:36descarga en tu sistema, el malicioso, el afectado, y entonces puede ejecutar
00:03:41código malicioso en tu sistema, normalmente con la ayuda de scripts de post-instalación.
00:03:47Por si no lo sabes, npm tiene este mecanismo de scripts.
00:03:56Todos los usamos en nuestros proyectos, por ejemplo, para iniciar un servidor de desarrollo, para compilar nuestro proyecto,
00:04:01para ejecutar pruebas, cosas así.
00:04:04Y específicamente también hay scripts de post-instalación, que podrías no estar usando cuando
00:04:11estás construyendo una app de React, por ejemplo, pero que las librerías a menudo usan o quizás no a menudo,
00:04:17pero pueden usar para ejecutar algún código en tu sistema después de instalar la librería, normalmente no
00:04:23para hacer nada malicioso o malo, sino, por ejemplo, para compilar algún código, crear un binario que
00:04:31pueda ser necesitado por esa librería, preparar tu sistema de cualquier forma para que realmente pueda
00:04:36usar esa librería que acabas de descargar.
00:04:40Esa es la idea detrás de un script de post-instalación.
00:04:42Permite que un paquete defina algún código que deba ejecutarse después de haber sido instalado
00:04:49a través de npm install, por ejemplo, y eso es exactamente lo que se suele aprovechar en esos
00:04:55ataques a la cadena de suministro.
00:04:57El atacante inyecta código malicioso en un paquete que es esencialmente un script de post-instalación
00:05:04que se ejecuta automáticamente una vez que el paquete infectado ha sido instalado.
00:05:10Normalmente ese código está ofuscado para que no sea fácil de leer.
00:05:14Podría estar codificado en base64 para que los escáneres que buscan código malicioso en los paquetes no lo
00:05:20detecten y/o el código malicioso puede ser descargado.
00:05:24Así que el script de post-instalación, como en este caso del ataque a Axios, en realidad no
00:05:30contiene directamente el código malicioso.
00:05:32En su lugar, contacta a un servidor y descarga el código desde allí.
00:05:36Eso es lo que pasó aquí.
00:05:37Y tenemos un informe detallado sobre qué pasó exactamente durante ese ataque.
00:05:41Lo encontrarás adjunto si quieres leer todos los detalles, pero allí esencialmente
00:05:45aprendemos que dos versiones del paquete Axios, 1.14.1 y 0.30.4 se vieron afectadas, fueron comprometidas
00:05:57al final y eso se hizo mediante el atacante obteniendo acceso a la cuenta de uno de los
00:06:02mantenedores del paquete Axios y usaron esa cuenta para publicar una nueva versión del paquete
00:06:08Axios que contenía una dependencia que a su vez contenía ese script de post-instalación.
00:06:14Así que ni siquiera fue el paquete Axios en sí el que contenía el script de post-instalación, sino
00:06:19que en su lugar fue otro paquete, el paquete plaincryptojs, que fue creado por el atacante,
00:06:25cuyo único propósito es tener un script de post-instalación que descarga y ejecuta código
00:06:31malicioso.
00:06:32Así que el paquete Axios fue comprometido al añadir plaincryptojs como una dependencia a Axios.
00:06:39Ese es un paquete malicioso.
00:06:40No sirve para otro propósito que descargar ese código malicioso y solo por añadir esta
00:06:46dependencia a Axios, el ataque estaba esencialmente terminado.
00:06:52Este paquete no se importa en el código fuente de Axios en ninguna parte.
00:06:56Solo tiene este script de post-instalación y eso es todo.
00:06:59Como se mencionó, entonces es capaz de descargar y ejecutar código desde macOS, Windows y Linux para
00:07:05¿entonces hacer qué?
00:07:06Bueno, robar un montón de cosas.
00:07:08Así que si tu sistema está afectado, como mencioné inicialmente, credenciales, claves API, tokens cripto,
00:07:14todas esas cosas divertidas están siendo recolectadas y exfiltradas por un troyano que se descarga mediante ese script de post
00:07:21instalación.
00:07:22Así es como funcionó ese ataque.
00:07:24Así es como funcionaron ataques similares en el pasado.
00:07:29Ahora lo que es un poco interesante, bueno, oh, por cierto, este ataque comenzó alrededor de la medianoche,
00:07:36exactamente después de la medianoche UTC hoy, hace unas horas.
00:07:40Duró un par de horas y ambas versiones de Axios, 1.14.1 y 0.30.4, se vieron afectadas en
00:07:5040 minutos, esencialmente 39 minutos para ser precisos.
00:07:53Así que este fue un ataque muy orquestado y planeado.
00:07:56Obviamente la creación de este paquete extra ocurrió creo que 18 horas antes de que el ataque
00:08:03comenzara.
00:08:04Fue muy orquestado y planeado.
00:08:06Ahora lo que es un poco raro aquí es que NPM tiene este mecanismo llamado publicación de confianza (trusted publishing),
00:08:14que puede ser usado por los mantenedores de paquetes.
00:08:17Y la idea aquí es que eso limita el proceso de publicación de nuevas versiones de un paquete a un proceso
00:08:26claramente definido donde específicamente tienes que compilar y publicar una nueva versión a través de
00:08:32uno de estos proveedores de CI/CD compatibles con una configuración determinada que debes seguir.
00:08:38Y la idea aquí es que incluso si roban las credenciales de tu cuenta de NPM, en teoría,
00:08:46el atacante no puede publicar una nueva versión de tu paquete desde su máquina porque
00:08:51necesita pasar por ese proceso.
00:08:52Ahora podrías argumentar que si la cuenta de GitHub de un mantenedor se ve comprometida, entonces tal vez
00:08:59se pueda subir una versión maliciosa a GitHub, activando ese flujo de trabajo de despliegue aquí y por lo tanto
00:09:06el código malicioso se publica a través de ese proceso de publicación de confianza.
00:09:11Pero según el informe de seguridad aquí, eso no fue lo que pasó.
00:09:16Porque el equipo de Axios está usando este proceso de publicación de confianza para la rama 1.x, no
00:09:21para la rama 0.30, sino para la rama 1.x.
00:09:26Pero según este informe, no hay ningún commit o ataque en el repositorio de GitHub de Axios.
00:09:33Así que no hubo un push a GitHub con esa versión comprometida de Axios.
00:09:40Por lo tanto, el proceso de publicación de confianza no debería haberse activado.
00:09:44En su lugar, este informe afirma que el atacante debe haber obtenido un token clásico de NPM de larga duración
00:09:50con acceso para publicar esta versión maliciosa o comprometida de Axios porque
00:09:56la versión solo existía en NPM, no en GitHub.
00:10:01Tal vez esto esté mal.
00:10:02Tal vez el ataque fue a través de GitHub.
00:10:05Sin embargo, si es correcto, no me queda claro cómo funcionó exactamente porque, en teoría,
00:10:11esta forma de publicar no debería ser posible cuando la publicación de confianza está activada.
00:10:15No estoy seguro si esto es alguna vulnerabilidad de seguridad o algún problema con NPM aquí.
00:10:20Que algunos tokens de larga duración existentes aún pudieran ser usados incluso con la publicación de confianza
00:10:26activada.
00:10:27Eso es algo que no pude descubrir, cómo exactamente funcionó eso.
00:10:32Y hay un hilo aquí, un issue de GitHub en la librería Axios donde se informó de este ataque.
00:10:39Por cierto, nota al margen, se crearon más issues similares y fueron borrados por el mantenedor
00:10:40comprometido, por la cuenta del mantenedor comprometido.
00:10:45Este hilo, este issue sobrevivió y el ataque fue detenido finalmente.
00:10:48Recuperaron el acceso a su cuenta, el mantenedor que fue afectado.
00:10:52Y en ese hilo, en ese issue, el mantenedor publica y dice que están usando publicación de
00:10:56confianza y no está claro cómo exactamente funcionó eso.
00:11:03Aquí hay una teoría que se compartió.
00:11:07Pero mi entendimiento es que esta teoría aún requeriría que una nueva versión maliciosa o comprometida
00:11:09fuera subida a GitHub, pero de nuevo, nada de eso está claro.
00:11:16Lo que está claro es que se han publicado versiones comprometidas que terminaron en NPM y
00:11:20por lo tanto pudieron ser descargadas en sistemas y robar cosas allí.
00:11:25Y por supuesto, con más de 80 millones de descargas semanales, hay mucho daño que se puede hacer en
00:11:29pocas horas.
00:11:35Obviamente las descargas no se distribuyen uniformemente durante todas las horas del día, pero este es
00:11:37definitivamente un número enorme y podemos asumir que miles, decenas de miles de sistemas
00:11:44se han visto afectados en esas pocas horas.
00:11:51Ahora, por supuesto, este no fue el primer ataque a la cadena de suministro.
00:11:55En los últimos meses hemos visto múltiples ataques.
00:11:59Un gran ataque a finales del año pasado, el ataque Shai-Hulud, donde múltiples paquetes fueron
00:12:01ejecutados en NPM y eso tenía un patrón similar, código malicioso siendo inyectado y ejecutado
00:12:08en sistemas que descargaron esos paquetes comprometidos y luego se robaron credenciales y demás.
00:12:16Así que ese es un gran ataque.
00:12:21Y luego, hace solo unos días, tuvimos un incidente similar en el ecosistema de Python.
00:12:22Así que no se limita a JavaScript, donde el paquete lightllm se vio afectado.
00:12:25Un paquete muy popular que al final facilita el uso de proveedores de IA a través de una
00:12:31interfaz conveniente, también tuvo un ataque similar y fue afectado.
00:12:37Y por lo tanto, por supuesto, no es solo JavaScript.
00:12:43Y creo que hay un par de razones por las que vemos que ocurren más ataques de este tipo.
00:12:49Porque, en teoría, este tipo de ataques podrían haber ocurrido y probablemente ocurrieron en el
00:12:52pasado también, pero claramente se están volviendo más frecuentes ahora y creo que hay un par
00:12:57de razones para ello.
00:13:03Ahora, por supuesto, una gran razón es que estamos en un momento en el que se escribe y se genera más código
00:13:08que nunca.
00:13:11Quiero decir, puedes mirar varias métricas.
00:13:17Por ejemplo, vi este gráfico recientemente donde el número de nuevos repositorios de GitHub creados
00:13:19está en un máximo histórico y, por supuesto, eso es debido a la IA.
00:13:22Donde la gente está trabajando en proyectos, está generando código.
00:13:27Tenemos más producción de código que nunca antes y, por supuesto, eso significa que con tantos
00:13:31más programas escritos, tanto más código generado, la superficie de ataque es mucho mayor.
00:13:35Hay más objetivos.
00:13:42Hay más gente construyendo o escribiendo código e instalando paquetes.
00:13:47Así que es más atractivo que nunca.
00:13:48No es que no fuera atractivo en el pasado, pero ahora hay más gente que nunca que
00:13:52puede ser atacada.
00:13:54Así que esa es, por supuesto, una gran razón.
00:13:59Es simplemente más interesante realizar estos ataques, pero no es la única razón.
00:14:00Creo que otra razón, por supuesto, también está relacionada con la IA, por un lado, realizar tales ataques como
00:14:03este con la ayuda de la IA probablemente se volvió más fácil, porque el código malicioso, por supuesto,
00:14:07también puede ser generado y escrito con ayuda de la IA, por lo que las habilidades técnicas necesarias para realizar tales
00:14:15ataques están más disponibles que en el pasado, diría yo, aunque también podrías comprar scripts
00:14:21o troyanos como estos en la darknet, pero aún así podría ser más accesible para la gente.
00:14:28Por supuesto, no es solo el lado bueno de la IA, que más gente pueda construir software y convertir
00:14:33sus ideas en negocios o lo que sea, sino que también está el lado malo.
00:14:40Más gente puede hacer cosas malas relacionadas con el código gracias a la IA, así que esa es una razón.
00:14:46También podrías argumentar que, por supuesto, los mantenedores de paquetes, los mantenedores de librerías están inundados
00:14:50con pull requests.
00:14:55Ese es otro gran problema que tenemos hoy en día, que si eres un mantenedor de código abierto hay
00:15:01más pull requests entrando que nunca antes, por lo que podrías no ser súper cuidadoso con lo que
00:15:02fusionas (merge).
00:15:07No es el problema aquí, solo para ser claros.
00:15:13En este ataque a Axios aquí claramente fue una cuenta comprometida, pero podrías, en teoría,
00:15:14argumentar que sería posible que los mantenedores fusionen código malicioso o código
00:15:16que instala dependencias maliciosas en su librería porque simplemente lo pasan por alto o tal vez
00:15:22porque tienen un proceso de revisión de código totalmente automatizado que no lo detecta.
00:15:29Simplemente confían en la IA.
00:15:34De nuevo, no es el caso aquí, pero podrías pensar que esto podría ser usado en el futuro por atacantes
00:15:38que inyecten código malicioso en bases de código porque la gente simplemente no mira.
00:15:40Además, cuando usas Claude Code, OpenClaude o lo que sea en tu sistema para hacer todo
00:15:45tipo de trabajo para ti, no solo para ayudarte a trabajar en software, sino tal vez solo para gestionar tu sistema
00:15:51como un todo, por supuesto, para ciertas tareas OpenClaude, Claude Code, Codec o lo que sea pueden decidir
00:15:56escribir algún script y ejecutar algún código para realizar una cierta tarea que les pidas y ese
00:16:01código que generaron también puede depender de dependencias como Axios.
00:16:09Así que de nuevo, la superficie de ataque se hace más grande, ese es mi primer argumento de nuevo, pero fuera
00:16:15del desarrollo de software clásico y por todas estas razones y probablemente muchas otras razones
00:16:20en las que no pensé aquí, estos ataques se están volviendo más lucrativos, más fáciles de hacer y más
00:16:24interesantes de hacer, y es por eso que estoy seguro de que veremos más de estos ataques en el futuro.
00:16:30Ahora, ¿qué puedes hacer para prevenir tales ataques y protegerte?
00:16:37Un gran paso adelante en seguridad, una cosa que puedes hacer es, en todos tus proyectos donde estés trabajando
00:16:43en aplicaciones y demás, cuando usas herramientas como pnpm en lugar de npm para gestionar
00:16:47tus dependencias, puedes añadir una configuración de antigüedad mínima de lanzamiento (minimum release age) a tu archivo pnpm-workspace.yaml.
00:16:55Bun tiene una función similar, puedes añadir un archivo bunfig.toml si usas bun como gestor de paquetes
00:17:02y también tienen una configuración de antigüedad mínima de lanzamiento que puedes añadir en ese archivo, ¿qué hace esto?
00:17:09Simplemente asegura que cada vez que instales un paquete, sin importar cómo, solo instale paquetes
00:17:15que tengan al menos esa antigüedad o versiones de paquetes que tengan al menos esa antigüedad, así que si un paquete
00:17:21fue comprometido hace cinco horas pero tienes una regla que solo instala versiones que
00:17:27tienen al menos tres días de antigüedad, deberías estar a salvo, esa es la idea y desafortunadamente npm en sí
00:17:34no tiene eso ahora, solo para estar seguros o que esto esté claro, seguimos hablando de paquetes
00:17:39que están alojados en npm, ese no es el problema, estoy hablando del gestor de paquetes aquí
00:17:46y puedes, por supuesto, usar bun o pnpm para descargar esos paquetes desde npm y si los estás
00:17:51usando en lugar de solo npm, la herramienta en sí, entonces puedes aprovechar configuraciones como esta
00:17:56que simplemente te dan esa capa extra de seguridad porque normalmente en el pasado esos ataques
00:18:03han sido detectados en un par de horas, así que si tienes un umbral de tres días, por
00:18:08ejemplo, la mayoría de estos ataques habrán sido detectados para entonces y habrán terminado, no es 100%
00:18:14seguro por supuesto, un ataque podría durar más, pero te da una ventaja clara y es
00:18:20definitivamente algo bueno que hacer ahora, para ser aún más seguro puedes y deberías considerar el uso de
00:18:25soluciones como Doppler y esto no está patrocinado, es solo un ejemplo, hay alternativas,
00:18:32yo construí mi propia alternativa en realidad, que uso yo mismo, que son servicios o herramientas que
00:18:39gestionan tus secretos, así que algo como tu clave API de OpenAI, podrías ponerla en un archivo
00:18:44.env, pero es mejor guardarla encriptada en o con la ayuda de un servicio como Doppler en
00:18:49sus servidores o alojada por ti mismo en un VPS que poseas y luego inyectarla en el entorno
00:18:55para que tu aplicación la conozca y la use cuando sea necesario, de modo que si tuvieras un
00:19:02troyano en tu sistema que tal vez recoja todos tus archivos .env y extraiga la información
00:19:08de ellos, no encuentre ningún secreto allí, esa es la idea, así que guardar esos secretos
00:19:13no en archivos de texto en tu sistema, y un archivo .env es solo un archivo de texto al final, sino
00:19:20encriptados en otro lugar es definitivamente también algo que podrías considerar hacer
00:19:25y de nuevo, hay diferentes soluciones aquí, pero es algo que podrías considerar
00:19:32y para ser aún más seguro, por supuesto, podrías externalizar tu entorno de desarrollo y
00:19:36no tenerlo en tu MacBook, tu máquina, tu PC, sino tenerlo en un VPS, en un Mac Mini
00:19:40al que te conectes vía SSH o algo así o tal vez en un contenedor de Docker para que
00:19:45si se ejecutara algún código malicioso allí, solo afecte a ese contenedor de Docker, a ese
00:19:50VPS y no a todo tu sistema, por lo que no puede recolectar todas las contraseñas de tu sistema y cosas
00:19:56así, en su lugar está aislado, tienes un radio de explosión más pequeño porque esos ataques
00:20:02seguirán ocurriendo obviamente, estoy seguro de que tendremos mejores y mejores mecanismos
00:20:07para asegurar la publicación de paquetes y demás, pero nunca habrá un 100% de garantía de que
00:20:13tales ataques no puedan ocurrir y por lo tanto tú como usuario de tales paquetes debes asegurar
00:20:21tu sistema y tener múltiples capas de defensa allí para disminuir la posibilidad de que
00:20:27descargues una versión de paquete comprometida y si lo haces, que el radio de explosión sea menor,
00:20:33eso es lo que puedes hacer, compartiré más sobre eso en futuros videos también en mi otro canal,
00:20:39el canal de la academia, pero sí, manténganse seguros, comprueben si han sido afectados por este
00:20:45ataque y sí, han sido un par de horas difíciles como mencioné.
00:20:50el canal de la academia, pero bueno, manténganse a salvo, comprueben si han sido afectados por este
00:20:55ataque y, sí, han sido un par de horas difíciles como mencioné