Ciberseguridad

El hackeo de paquetes de Rust planta malware para robar información en los dispositivos de los desarrolladores

Las cuentas de mantenimiento de paquetes de Rust fueron comprometidas, lo que provocó la publicación de versiones maliciosas de arrayref y otros dos paquetes, además de la ejecución de malware durante el proceso de compilación. El malware atacó datos del sistema y credenciales de navegadores, y se recomienda a los desarrolladores que utilizaron las versiones afectadas durante la ventana de exposición reconstruir sus entornos y rotar los secretos.

2026-08-20
4 min de lectura
12 visitas
فريق تحرير certi.news
El hackeo de paquetes de Rust planta malware para robar información en los dispositivos de los desarrolladores

Los atacantes explotaron una cuenta de mantenimiento vinculada al popular paquete de Rust arrayref para publicar una versión maliciosa que ejecuta malware en los dispositivos de los desarrolladores durante la compilación de proyectos. Durante una ventana temporal de no más de 23 minutos, la operación también afectó a los paquetes append-only-vec e internment, en un ataque a la cadena de suministro de software.

StepSecurity informó de que las versiones afectadas son arrayref 0.3.10, append-only-vec 0.1.9 e internment 0.8.7, y que los tres paquetes estaban gestionados por la misma cuenta. arrayref está ampliamente extendido: registró más de 53 millones de descargas durante los últimos 90 días y más de 245 millones de descargas en total. Se utiliza en proyectos y herramientas relacionados con la criptografía, los gráficos y las interfaces gráficas de Rust, además de componentes empleados en los ecosistemas de Ethereum y Solana.

¿Cómo se ejecutó el ataque?

Los atacantes añadieron una dependencia del paquete llamado proc-macro1, que suplanta el nombre del conocido paquete proc-macro2. La mayor parte del código fuente original de los paquetes permaneció sin cambios, lo que dificulta la manipulación para quienes solo revisan las diferencias de código.

proc-macro1 contenía un archivo build.rs que se ejecuta automáticamente durante la compilación. El archivo reconstruye los componentes de la estructura maliciosa a partir de partes codificadas en Base64 y luego selecciona una carga útil adecuada para el sistema operativo, incluidos Linux, Windows y macOS con arquitecturas x86-64 y ARM64. En Unix, la carga útil se escribe en /tmp/rust-setup y se ejecuta como un proceso independiente, mientras que en Windows el ataque crea un archivo llamado rust-setup.ps1 dentro de la carpeta TEMP y utiliza wscript.exe y un ejecutor en formato VBS para mantener el proceso en ejecución.

¿Qué puede robar el malware?

Según el análisis de Wiz, la segunda fase recopila información del host y credenciales. El malware extrae datos de inicio de sesión de las bases de datos SQLite de los navegadores Google Chrome, Brave y Edge. También crea mecanismos de persistencia mediante Registry Run en Windows, LaunchAgent en macOS y systemd en Linux. La carga útil recibe una dirección como argumento, que se cree que es la dirección de un servidor de mando y control.

Cronología y qué significa para los desarrolladores

La campaña comenzó a las 01:17 UTC del 20 de agosto de 2026, con la creación de una cuenta de GitHub que suplantaba la identidad del destacado desarrollador de Rust David Tolnay, seguida de una cuenta similar en crates.io. Se publicó una versión limpia de proc-macro1 a las 01:55, seguida de la versión maliciosa 1.0.107 a las 07:11. Cuatro minutos después, se publicó arrayref 0.3.10 mediante la cuenta legítima droundy, vinculada a David Roundy, y se eliminaron las versiones 0.3.5 a 0.3.9, lo que podría llevar a las herramientas de instalación a elegir la versión maliciosa.

El incidente fue comunicado a las 07:54; crates.io eliminó el paquete proc-macro1 a las 08:03 y retiró arrayref 0.3.10 del índice a las 08:41. También se eliminaron versiones maliciosas de otros paquetes: aovine, arone, aronenao y tinymember.

Medidas de respuesta

Quienes instalaron las versiones afectadas durante la ventana de exposición, que duró aproximadamente una hora y media, deben tratar el entorno como comprometido. La revisión incluye buscar las versiones sospechosas en los archivos Cargo.lock, comprobar qué archivos fueron depositados y analizar las conexiones a la dirección 23.254.165[.]112 a través de los puertos 9089 y 443. Si se confirma el compromiso, los análisis recomiendan rotar todas las credenciales, los tokens de CI, las claves de firma y los demás secretos, y después reconstruir el entorno a partir de copias de seguridad fiables. En cuanto a los proyectos no afectados, deben fijar una versión conocida como segura hasta que se aclare la situación de las cuentas de mantenimiento.

Fuente de la noticia
BleepingComputer
Abrir fuente original ↗
ف
Autor

فريق تحرير certi.news

De la misma categoría

También te puede interesar

Ver todas las noticias