Axios bajo fuego: así se gestó el ataque a la cadena de suministro en npm

Home » Python » Axios bajo fuego: así se gestó el ataque a la cadena de suministro en npm

Durante unas horas de tensión, una de las bibliotecas de JavaScript más utilizadas del planeta, Axios, se convirtió en un vehículo de entrega inesperado para el malware. Un objetivo Ataque a la cadena de suministro del ecosistema npm Convirtieron una actualización rutinaria de dependencias en una posible puerta trasera para atacantes en cientos de miles de máquinas de desarrolladores y sistemas de compilación.

Investigadores de varias empresas de seguridad y del Grupo de Inteligencia de Amenazas de Google reconstruyeron cómo un actor malicioso logró infiltrarse en un sistema. troyano de acceso remoto (RAT) en versiones específicas de Axios en npm, de forma similar a la gusano de la cadena de suministro de npm.

Qué es Axios y por qué el compromiso es tan importante.

En esencia, Axios es un Cliente HTTP basado en promesas para Node.js y navegadoresEstá presente en segundo plano en innumerables proyectos, gestionando tareas cotidianas como "obtener mis mensajes del servidor" o "enviar este formulario a la API" sin que los desarrolladores tengan que escribir manualmente código de red de bajo nivel.

Debido a que se ejecuta tanto en el navegador como en servidores Node.js, Axios se ha convertido en un dependencia fundamental en las pilas de JavaScript modernasPuede que nunca lo hayas instalado explícitamente, pero aun así dependes de él indirectamente cuando:

• Utilice aplicaciones web creadas con frameworks como React, Vue o Angular que encapsulen sus llamadas a la API con Axios.
• Ejecuta aplicaciones de escritorio o móviles creadas con tecnologías como Electron, React Native y entornos de ejecución web similares.
• Interactúa con herramientas SaaS más pequeñas, paneles de administración o servicios autohospedados cuyos desarrolladores eligieron Axios para las solicitudes HTTP.

En ese sentido, Axios es un poco como el fontanería en su casaRara vez lo piensas, pero transporta los datos entre tu aplicación y el mundo exterior. Solo te das cuenta cuando hay una fuga, justo lo que provocó este ataque, pero a escala del ecosistema de software.

Cómo se desarrolló el ataque de Axios a npm

El incidente se centra en dos versiones de npm: axios@1.14.1 además axios@0.30.4Utilizando credenciales comprometidas de uno de los principales mantenedores del proyecto, los atacantes lograron publicar compilaciones maliciosas directamente a npm mientras se deja intacto el código fuente público de GitHub, un patrón también descrito en el Análisis de Shai-Hulud.

En lugar de alterar visiblemente el código de Axios, el atacante añadió una nueva dependencia, aparentemente sin relación alguna: plain-crypto-js@4.2.1Este paquete fue diseñado específicamente para la operación y no se importó en ninguna parte de los archivos fuente de Axios, una señal de alerta para cualquiera que examine las diferencias, pero fácil de pasar por alto en flujos de trabajo automatizados que simplemente confían en el registro.

En conjunto, las dos versiones contaminadas de axios tenían una huella potencial enorme, que llegaba hasta alrededor de 100 millones de descargas semanales en npmSe estima que Axios está presente en cerca del 80 % de los entornos en la nube y las canalizaciones de CI/CD, por lo que incluso un breve período de exposición representaba un grave riesgo sistémico.

Fundamentalmente, las versiones afectadas nunca aparecieron en el Etiquetas oficiales de GitHub para el proyecto Axios. Ese detalle sugiere firmemente que se eludieron los procesos de lanzamiento normales: el atacante aprovechó un token npm robado para enviar paquetes directamente al registro, fuera del historial de código fuente público.

La mecánica de la dependencia maliciosa y el RAT

El meollo del problema reside en lo que ocurrió en el momento de la instalación. Cualquier flujo de trabajo que se ejecutara npm install y se detuvo axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 Con los scripts habilitados, se activó una rutina posterior a la instalación oculta.

Dentro de la dependencia maliciosa, un Script de postinstalación (node ​​setup.js) ejecutado automáticamente. Ese script descargó un dropper ofuscado, que luego obtuvo una carga útil RAT específica de la plataforma adaptada a macOS, Windows o LinuxEl RAT otorgó al atacante acceso remoto interactivo a la máquina comprometida.

Una vez activo, este troyano de acceso remoto podría enumerar el sistema, robar secretos y ejecutar comandos arbitrarios. Piénsalo. claves de API en la nube, tokens de implementación de CI, tokens de autenticación de npm, claves SSH, tokens de acceso al repositorio y otras variables de entorno sensibles Se inyecta habitualmente en agentes de compilación o portátiles de desarrolladores.

Desde ahí, los atacantes podrían cambiar de estrategia: revisar el código fuente, manipular versiones futuras, agregar más puertas traseras o moverse lateralmente a la infraestructura de producción. Para los desarrolladores que trabajan en proyectos relacionados con criptomonedas (billeteras, intercambios, interfaces DeFi), este tipo de acceso podría traducirse directamente en robo de criptomonedas o fraude financiero más amplio.

Tácticas de sigilo: por qué fue difícil detectar el compromiso

Los autores del malware hicieron todo lo posible para que su huella fuera lo más pequeña y efímera posible. Según los investigadores, el dropper limpió sus huellas inmediatamente después de la ejecución.

Eso significa que si examinas node_modules/plain-crypto-js/package.json después infección, verías un manifiesto completamente inocuo: sin script postinstalación, sin setup.js, sin indicadores obvios de juego sucio. Herramientas estándar como npm audit o una simple comprobación manual del directorio no revelaría lo que ya había sucedido.

En la práctica, este comportamiento hizo que los investigadores dependieran de fuentes externas. indicadores de compromiso (IOC)Se utilizaron telemetría de red y artefactos del host en lugar de simples escaneos estáticos del contenido del paquete npm. Para cuando el ataque se hizo público, las versiones maliciosas ya se habían retirado de npm, lo que complicó aún más la reconstrucción del flujo de ejecución exacto.

Indicadores clave de compromiso en el incidente de Axios

Aunque el malware intentó ocultar sus huellas, los equipos de seguridad han compartido indicadores de compromiso (IOC) concretos que pueden ayudar a determinar si un entorno se vio afectado. Entre los más importantes se encuentran los siguientes:

En la pestaña lado de la red, busque comunicación con:

• Dominio: sfrclakcom
• Dirección IP: 142.11.206.73

Ambos indicadores han sido bloqueados por los principales proveedores de seguridad, pero siguen siendo marcadores útiles en los registros históricos y en las búsquedas de SIEM.

En la pestaña sistema de archivosLos investigadores destacaron artefactos asociados con la prueba RAT:

• Mac OS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: archivos en %PROGRAMDATA%\wt y scripts temporales como %TEMP%\6202033.vbs or .ps1 que puede existir solo brevemente durante la ejecución

En términos de paquetes npm, el compilaciones comprometidas y sus sumas de verificación conocidas son:

• axios@1.14.1, SHA-256: 2553649f2322049666871cea80a5d0d6adc700ca
• axios@0.30.4, SHA-256: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• plain-crypto-js@4.2.1, SHA-256: 07d889e2dadce6f3910dcbc253317d28ca61c766

Empresas de seguridad como Huntress observaron al menos 135 sistemas contactando con el servidor de comando y control del atacante. Durante el período de exposición relativamente corto, los investigadores de Google advirtieron que, como resultado, podrían haberse sustraído "cientos de miles" de secretos.

¿Quién estuvo detrás del ataque? Atribución y vínculo con Corea del Norte.

El Grupo de Inteligencia de Amenazas de Google ha vinculado públicamente la vulneración de Axios con un presunto actor amenazante de Corea del Norte rastreado como UNC1069. John Hultquist, analista jefe de la unidad de amenazas de Google, señaló que los operadores norcoreanos tienen un largo historial de Ataques a la cadena de suministro destinados a robar criptomonedas y otros activos.

Según Google y otros proveedores de seguridad, el incidente de Axios parece ser parte de una campaña más amplia de grupos norcoreanos, incluyendo organizaciones como Lazarus, que se centran en extorsión, robo financiero y exfiltración de datos Dirigido a sectores como las criptomonedas, las tecnologías financieras y la infraestructura en la nube.

Aunque el impacto total aún no está claro, la combinación de un paquete enormemente popular, el acceso a entornos de desarrollo y la naturaleza de los datos robados lleva a los analistas a esperar ataques posteriores en forma de nuevas vulneraciones de la cadena de suministro, ataques de ransomware y robo directo de criptomonedas.

Cómo se abusó de la cuenta de mantenedor y del flujo de trabajo de npm

Uno de los aspectos más inquietantes para la comunidad de código abierto es cómo los atacantes lograron publicar versiones maliciosas de Axios sin tocar el código fuente público. La clave fue un Cuenta de mantenedor comprometida en npm, que se cree que pertenece a un mantenedor principal de Axios conocido como jasonsaayman.

Según los informes, los atacantes cambiaron la dirección de correo electrónico asociada con esa cuenta de npm a una dirección bajo su control. Con ese paso, pudieron... bloquear al mantenedor legítimo y publicar nuevas versiones de paquetes como si fueran actualizaciones legítimas, todo ello mientras el repositorio oficial de GitHub permanecía limpio.

La operación también puso de manifiesto un problema estructural en npm: el soporte para tokens de autenticación heredados, y la necesidad de herramientas de gestión de la cadena de suministro y políticas de tokens más estrictas.

En este caso, los investigadores de seguridad señalaron que npm todavía Se optó por el token anterior. para la publicación, y ningún control revocaba automáticamente ese token una vez que se configuraban métodos de publicación más modernos. Esa coexistencia creó una puerta lateral vulnerable que UNC1069 podía explotar.

Ventana de exposición y detección temprana

La vulneración de Axios no fue un proceso lento y prolongado. Las investigaciones sugieren que las versiones maliciosas fueron... Disponible en npm durante aproximadamente tres horas. Entre la noche del domingo y la madrugada del lunes o martes, dependiendo de la zona horaria.

StepSecurity y otras empresas señalaron que el atacante había sembrado el ecosistema con un versión limpia de la dependencia maliciosa aproximadamente 18 horas antes adjuntar la variante modificada a Axios. Esta medida parece haber sido diseñada para crear un historial inofensivo para el paquete y evitar que se activaran los detectores de anomalías automatizados cuando la dependencia apareciera repentinamente.

Una vez que las versiones infectadas de Axios se pusieron en marcha, el troyano realizó un reconocimiento exhaustivo en cada sistema donde se ejecutó: Escaneo de directorios, listado de procesos en ejecución, enumeración de discos y luego enviar esa información de vuelta al servidor del atacante. Todo esto sucedió en segundo plano durante lo que, para los desarrolladores, parecía una instalación de dependencias rutinaria.

Gracias a la respuesta coordinada del mantenedor, npm y varios proveedores de seguridad, las versiones maliciosas fueron retiradas en cuestión de horas. Sin embargo, como destacaron varios investigadores y el propio equipo de Google, Un período de exposición corto no es lo mismo que un riesgo bajo. cuando el objetivo es una biblioteca con decenas de millones de descargas semanales.

Impacto en desarrolladores, proyectos de criptomonedas y usuarios finales

Desde un punto de vista práctico, las víctimas más directas del incidente de Axios son: desarrolladores y entornos de compilación que instalaron las versiones maliciosas. Cualquiera que haya ejecutado una instalación o compilación que haya incluido axios@1.14.1, axios@0.30.4 o plain-crypto-js@4.2.1 con scripts habilitados debe asumir que el sistema podría estar totalmente comprometido.

Para los proyectos en el espacio de las criptomonedas (billeteras, intercambios centralizados y descentralizados, paneles DeFi, bots de trading y frontends Web3), lo que está en juego es particularmente importante. Muchos de estos sistemas Dependemos de Axios para comunicarnos con pasarelas blockchain, API y servicios de backend.y, a menudo, gestionan información confidencial como claves privadas, credenciales de API y datos de usuarios.

Si una estación de trabajo de desarrollador o un agente de CI en un proyecto de este tipo estuviera infectado, los atacantes podrían haber obtenido no solo los secretos almacenados localmente, sino también acceso a repositorios y pipelines de despliegueDe este modo, podrían inyectar código malicioso en futuras versiones, comprometer indirectamente a los usuarios finales o desviar fondos.

Por el contrario, los usuarios que simplemente ejecutan aplicaciones terminadas en su navegador están en una mejor posición: el RAT se entregó durante Pasos de instalación y montajeNo durante la ejecución en el navegador. Por lo tanto, visitar un sitio que utiliza Axios para las llamadas del lado del cliente no activa el ataque por sí solo. El riesgo se concentra en quienes instalaron los paquetes npm afectados.

Medidas inmediatas que deben tomar los desarrolladores

Los equipos de seguridad y los mantenedores han sido claros: si existe alguna posibilidad de que sus sistemas hayan descargado las versiones comprometidas de Axios o plain-crypto-js, trate esos hosts como No es de fiar en absoluto hasta que se investigue.Eso significa algo más que simplemente cambiar el número de versión.

Entre las medidas concretas recomendadas por investigadores y proveedores se incluyen:

• Revisa tus dependencias y archivos de bloqueo: Busque axios@1.14.1, axios@0.30.4 además plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock y registros de CI; ver cómo repararlos de forma segura.
• Actualiza a versiones seguras y verificadas: Utilice versiones limpias de Axios (por ejemplo, las etiquetas parcheadas inmediatamente posteriores recomendadas por los responsables del mantenimiento) y asegúrese de que sus archivos de bloqueo se regeneren.
• Renueve sus credenciales con frecuencia: Suponga que cualquier secreto presente en las máquinas o canalizaciones afectadas (claves de API en la nube, tokens de npm, claves SSH, claves de implementación, variables .env) puede haber sido robado y rótelos.
• Reconstruir sistemas comprometidos: Siempre que sea posible, vuelva a implementar los agentes de compilación, los ejecutores de CI y las estaciones de trabajo de los desarrolladores a partir de imágenes de confianza, en lugar de intentar limpiarlos in situ.
• Infraestructura del bloque C2: Agregar la extensión de sfrclak.com además 142.11.206.73 a cortafuegos, listas de bloqueo DNS y reglas EDR.
• Búsqueda de artefactos: Verifique las rutas del sistema de archivos y los archivos temporales asociados con el RAT en hosts macOS, Windows y Linux.

Varias empresas de seguridad han aconsejado a las organizaciones que instalaron las versiones contaminadas que presumir compromiso por defectoEn otras palabras, proceda bajo el supuesto de que los atacantes tuvieron acceso y siga sistemáticamente los pasos de respuesta al incidente en lugar de esperar que el malware no haya hecho nada.

Lecciones más amplias para la seguridad de la cadena de suministro de software

Más allá del triaje inmediato, el incidente de Axios ha reavivado los debates sobre cómo el ecosistema más amplio maneja la confianza, la identidad y la distribución en el código abierto. Ilustra cómo un cuenta de administrador de biblioteca única Puede convertirse en un elemento clave para la postura de seguridad de innumerables organizaciones.

De los análisis posteriores a los incidentes y de los análisis de los proveedores han surgido varios temas:

• Los tokens heredados representan un riesgo: Los tokens antiguos de npm pueden persistir discretamente junto con los flujos de trabajo más recientes basados ​​en OIDC. Los proyectos necesitan políticas explícitas para revocarlos una vez que se implementen métodos más seguros.
• Las actualizaciones automáticas tienen dos caras: Las actualizaciones automáticas de dependencias aceleran el desarrollo, pero también implican que una versión maliciosa puede propagarse por los ecosistemas antes de que nadie se dé cuenta.
• El análisis de dependencias es necesario pero no suficiente: Comprobaciones estáticas y npm audit son útiles, pero luchan contra comportamiento efímero como los scripts de postinstalación que se autodestruyen.
• La seguridad del personal de mantenimiento es una infraestructura crítica: La autenticación multifactor robusta, las claves de seguridad de hardware, el manejo cuidadoso de los tokens de acceso y la revisión periódica de quién puede publicar son ahora tan importantes como escribir buen código.

Para los fundadores, los CTO y los líderes de ingeniería, el compromiso de Axios es un recordatorio de que El riesgo en la cadena de suministro es una cuestión estratégica.No se trata solo de un aspecto técnico. Afecta a la rapidez con la que se pueden realizar los envíos, al diseño de las canalizaciones de CI/CD y a cómo se equilibra la comodidad del código abierto con la necesidad de verificar lo que se ejecuta en producción.

En conjunto, la vulnerabilidad de Axios en npm demuestra cómo un ataque breve pero bien planificado puede convertir un componente fundamental del ecosistema JavaScript en una vía sigilosa para el malware de acceso remoto. Dado que los atacantes se dirigen tanto a los mantenedores y canales de distribución como a los usuarios finales, mantener la salud de las cadenas de suministro de software depende ahora de controles más estrictos en los flujos de trabajo de publicación, una monitorización exhaustiva de las anomalías y la voluntad de tratar las dependencias con el mismo escepticismo que antes se reservaba solo para el tráfico de red externo.

Artículo relacionado:

Guía detallada sobre auditorías de seguridad de NPM y ataques a la cadena de suministro