NoticiasMacroAtaque coordinado a la cadena de suministro afecta a populares crates de Rust con malware en tiempo de compilación

Ataque coordinado a la cadena de suministro afecta a populares crates de Rust con malware en tiempo de compilación

Autor: Metaverse Post·

Puntos clave

  • Versiones maliciosas de los crates de Rust arrayref, internment y append-only-vec fueron modificadas para depender de proc-macro1, un typosquat de proc-macro2 que ejecutaba malware durante las compilaciones de Cargo.
  • El implante multiplataforma infectaba sistemas Linux, macOS y Windows, recolectando detalles del sistema y datos de navegación de Chromium mientras establecía persistencia y comunicación de comando y control.
  • El Equipo de Respuesta de Seguridad de Rust eliminó las versiones contaminadas y bloqueó la cuenta del mantenedor, concluyendo que lo más probable es que la máquina del desarrollador o sus credenciales de publicación hubieran sido comprometidas, y no que el mantenedor hubiera actuado con malicia.
  • arrayref había acumulado aproximadamente 152 millones de descargas y aparece en árboles de dependencias que incluyen componentes relacionados con Solana, lo que crea una amplia superficie de ataque en máquinas de desarrolladores e infraestructura de CI/CD.
  • Dado que Cargo omite las versiones retiradas (yanked) al calcular árboles de dependencias nuevos, pero respeta las versiones ya registradas en los archivos Cargo.lock, la exposición real depende del lockfile fijado de cada proyecto.
Ataque coordinado a la cadena de suministro afecta a populares crates de Rust con malware en tiempo de compilación

El 20 de agosto de 2026, investigadores de seguridad identificaron un ataque coordinado a la cadena de suministro contra tres crates de Rust de uso generalizado publicados en crates.io. Los paquetes comprometidos—arrayref versión 0.3.10, internment 0.8.7 y append-only-vec 0.1.9—fueron alterados para incluir una dependencia maliciosa que ejecutaba código remoto durante la compilación estándar. El Equipo de Respuesta de Seguridad de Rust eliminó rápidamente las versiones afectadas y bloqueó la cuenta del mantenedor, señalando que lo más probable es que la máquina del desarrollador legítimo o sus credenciales de publicación hubieran sido comprometidas, y no que el mantenedor hubiera actuado con intención maliciosa.

La dependencia typosquat entregó la carga maliciosa

El ataque aprovechó un crate typosquat llamado proc-macro1, que suplantaba a la biblioteca legítima proc-macro2. Cuando Cargo resolvía la dependencia, ejecutaba automáticamente un script de compilación malicioso que reconstruía direcciones de comando y control a partir de datos ofuscados en Base64, desactivaba la verificación TLS y descargaba una carga maliciosa específica para cada plataforma desde un servidor controlado por los atacantes. Dado que el compromiso se producía en tiempo de compilación, el simple hecho de compilar un proyecto que dependiera de manera transitiva de uno de los crates maliciosos podía infectar una estación de trabajo de desarrollo o un host de integración continua, aunque el código de la aplicación nunca invocara directamente ninguna función sospechosa.

La suplantación apuntaba a uno de los componentes más ubicuos de Rust—proc-macro2 es la base del manejo de macros para una gran parte de los crates publicados—y registros como crates.io, npm y PyPI asignan los nombres de los paquetes por orden de llegada, una política que desde hace tiempo ha convertido al typosquatting en una técnica favorita de ataque a la cadena de suministro en los ecosistemas de los distintos lenguajes.

Comportamiento del backdoor multiplataforma

El malware operaba en Linux, macOS y Windows. En Linux y macOS, depositaba un ejecutable en directorios temporales y lo lanzaba de forma desvinculada. En Windows, desplegaba scripts de PowerShell y Visual Basic para eludir las políticas de ejecución y correr procesos ocultos. El backdoor de segunda etapa luego perfilaba el sistema infectado, recolectando nombres de usuario, nombres de host, aplicaciones instaladas y datos de navegación de navegadores basados en Chromium. Establecía persistencia a nivel de usuario mediante claves run del registro, servicios de usuario de systemd o LaunchAgents de macOS, mantenía comunicación con un endpoint de comando y control y admitía instrucciones remotas para posteriores ejecuciones y cambios de configuración.

La firma de seguridad Socket documentó el compromiso en X:

Popular Rust crates compromised: Affected versions of arrayref, internment, and append-only-vec were modified to depend on proc-macro1, a malicious typosquat of proc-macro2. Its build script downloaded and executed malware during Cargo builds. Analysis:

— Socket (@SocketSecurity), August 20, 2026

Exposición más amplia del ecosistema y remediación

El incidente tiene implicaciones significativas para el ecosistema de Rust y para la infraestructura blockchain adyacente. Solo arrayref había acumulado aproximadamente 152 millones de descargas antes del compromiso y se ubica dentro de árboles de dependencias que incluyen componentes relacionados con Solana y frameworks populares de interfaz gráfica. Aunque los proyectos posteriores no estaban comprometidos por defecto, salvo que hubieran resuelto y compilado explícitamente las versiones maliciosas, el amplio uso transitivo del crate crea una gran superficie de ataque que abarca entornos de desarrollo, pipelines de CI/CD e infraestructura de publicación automatizada que a menudo alberga tokens sensibles y material de firma.

El episodio también se produce en medio de una ola más amplia de compromisos en registros de paquetes. En agosto de 2025, una campaña rastreada como rk0x utilizó credenciales robadas de mantenedores para publicar versiones infectadas con malware de crates populares de Rust, robando credenciales de navegadores y billeteras de criptomonedas, mientras que npm y PyPI han enfrentado repetidamente campañas de typosquatting y apropiación de cuentas. Asimismo, la puerta trasera en XZ Utils de marzo de 2024 demostró cómo una única biblioteca de código abierto ampliamente utilizada puede convertirse en un punto de estrangulamiento que alcanza a una gran cantidad de sistemas posteriores.

Los investigadores identificaron crates de preparación adicionales controlados por los atacantes—proc-macro-en, aovine, arone, aronenao y tinymember—que posteriormente fueron eliminados del registro. El actor de amenazas también retiró (yanked) versiones legítimas previas de arrayref, orientando potencialmente la resolución de dependencias hacia la versión maliciosa antes de que intervinieran los administradores. Según las reglas de resolución de Cargo, las versiones retiradas se omiten al calcular árboles de dependencias nuevos, aunque las versiones ya registradas en un Cargo.lock siguen compilándose, por lo que la exposición real depende de los lockfiles fijados y no solo del estado del registro.

Se recomienda a las organizaciones auditar los archivos Cargo.lock, los inventarios de dependencias y los registros de compilación en busca de las versiones afectadas y de indicadores relacionados. Cualquier sistema que haya compilado una de las versiones maliciosas debe tratarse como potencialmente comprometido, lo que requiere rotar los secretos accesibles desde el entorno de compilación, realizar búsquedas forenses de artefactos de red y de host conocidos y recompilar el software desde entornos limpios verificados. Los defensores también deben monitorear las conexiones a la infraestructura de comando y control identificada y las salidas deterministas del algoritmo de generación de dominios asociado al implante. Las herramientas del ecosistema apoyan este análisis: cargo tree enumera las dependencias transitivas para su revisión, y la base de datos de advisories de RustSec, consultada mediante cargo audit, cataloga las versiones de crates con vulnerabilidades conocidas.

Fuente: Metaverse Post