Los hackers comprometieron la cuenta del mantenedor detrás del crate arrayref, ampliamente utilizado en Rust, para introducir malware que se ejecutaba en los sistemas de los desarrolladores durante la compilación. En una ventana de 23 minutos, el atacante también envenenó otros dos crates, append-only-vec e internment, en el mismo ataque a la cadena de suministro.
El crate arrayref es una biblioteca popular de Rust con más de 53 millones de descargas en los últimos 90 días, utilizada en herramientas de criptografía, gráficos y blockchain. Según un informe de la empresa de seguridad de aplicaciones StepSecurity, las versiones maliciosas de los crates fueron arrayref 0.3.10, append-only-vec 0.1.9 e internment 0.8.7, todas mantenidas por la misma cuenta.
El hacker inyectó una dependencia de un paquete llamado proc-macro1, un typosquat que suplanta al popular crate proc-macro2, mientras que el resto del código fuente original permaneció sin cambios. Según los investigadores, un script en proc-macro1 llamado 'build.rs' se ejecuta automáticamente durante la compilación, reconstruyendo su infraestructura a partir de fragmentos codificados en base64 y seleccionando un payload que coincide con el sistema operativo del host (Linux x86-64, Windows x86-64, macOS x86-64 y macOS ARM64).
StepSecurity dice que el atacante también publicó múltiples versiones de cuatro crates propios (aovine, arone, aronenao, tinymember), que han sido eliminados de crates.io. En sistemas Unix, el malware escribe en /tmp/rust-setup, lo marca como ejecutable y lo lanza como un proceso separado. En Windows, crea %TEMP%rust-setup.ps1 y utiliza un wscript.exe oculto y un lanzador VBS para mantener el proceso en ejecución. El payload recibe una dirección como argumento, que se cree es una dirección de comando y control.
Según un análisis de la empresa de seguridad en la nube Wiz, las capacidades de segunda etapa incluyen la exfiltración de información del host y credenciales. Los investigadores dicen que el malware recopila credenciales de los navegadores Google Chrome, Brave y Edge consultando las bases de datos SQLite de login. La persistencia se establece mediante la clave de Registro Run en Windows, LaunchAgent en macOS y systemd en Linux.
Cronología e impacto
El impacto potencial de este ataque a la cadena de suministro es significativo, ya que arrayref solo tiene más de 245 millones de descargas de por vida, mientras que el recuento colectivo de append-only-vec e internment es de casi 19 millones de instalaciones. Los proyectos que utilizan arrayref incluyen blake3, marcos de GUI de Rust como egui, eframe e iced, y componentes utilizados en Ethereum y Solana.
El ataque comenzó a las 01:17 UTC del 20 de agosto, cuando se creó una cuenta de GitHub que suplantaba al prominente desarrollador de Rust David Tolnay, seguida de una cuenta similar en el registro crates.io. A las 01:55, el atacante publicó proc-macro1@1.0.106, una copia benigna de proc-macro2, seguida de una actualización maliciosa a través de la versión 1.0.107, publicada a las 7:11. El incidente fue reportado a las 07:54. Crates.io eliminó proc-macro1 a las 08:03 y retiró arrayref 0.3.10 del índice a las 08:41.
Las empresas de ciberseguridad StepSecurity, SafeDep y Aikido han publicado cada una un análisis técnico del ataque a la cadena de suministro y han compartido indicadores de compromiso. Los investigadores de Wiz señalan que 'la infraestructura de la campaña se superpone con los recientes ataques a la cadena de suministro de la RPDC [Corea del Norte], incluidos Mastra y axios'.
Los desarrolladores que instalaron cualquiera de estos paquetes durante la ventana de exposición de casi 1.5 horas deben asumir que están comprometidos. Las comprobaciones recomendadas incluyen buscar en los archivos Cargo.lock, buscar los archivos eliminados y revisar el tráfico a 23.254.165[.]112 en los puertos 9089 y 443. Si se confirma el compromiso, se recomienda rotar todas las credenciales accesibles, tokens de CI, claves de firma y otros secretos, y reconstruir el entorno a partir de copias de seguridad seguras. Los proyectos limpios deben fijar una versión conocida segura de las dependencias afectadas hasta que se aclare y resuelva la situación del mantenedor.
Deja una respuesta