MagnoSec
Código Rust con cajas de crates representando el ataque a la cadena de suministro que introdujo malware en crates con 245 millones de descargas

MagnoSec Blog

Ataque a la Cadena de Suministro de Rust Introduce Malware en Crates con 245 Millones de Descargas

Por Equipo MagnoSec7 min de lectura

Rust bajo ataque: el malware que se esconde en el proceso de compilación de crates con 245 millones de descargas

Rust es el lenguaje de programación que promete seguridad en memoria por diseño —sin buffer overflows, sin use-after-free, sin las clases de vulnerabilidades que han atormentado a C y C++ durante décadas—. Pero la seguridad del lenguaje no protege contra la inseguridad de su cadena de suministro. Un ataque sofisticado ha comprometido múltiples crates de Rust —los paquetes de librerías que los desarrolladores descargan de crates.io— e inyectado malware que se activa durante el proceso de compilación. Los crates afectados acumulan más de 245 millones de descargas. La técnica utilizada es particularmente insidiosa: en lugar de incluir código malicioso visible en el código fuente del crate —que podría ser detectado por una revisión manual o por herramientas de análisis—, los atacantes manipularon el proceso de build del crate para que el malware se genere y se compile dinámicamente durante la compilación. El código fuente que los desarrolladores descargan parece limpio. El malware solo existe durante el build, cuando el compilador ejecuta los scripts de build del crate (build.rs) y genera el binario final. Para cuando el desarrollador tiene un ejecutable compilado, el malware ya está dentro. Y no hay rastro visible en el repositorio de código fuente. Es un ataque diseñado para evadir exactamente los controles de seguridad que los desarrolladores de Rust suelen aplicar: revisión de código y análisis de dependencias. El malware no está en el código. Está en el proceso que lo compila.

Crates.io y el ecosistema Rust: la cadena de suministro de un lenguaje que promete seguridad en memoria

El ecosistema Rust ha crecido explosivamente en los últimos años. Rust es el lenguaje elegido para proyectos de infraestructura crítica: los kernels experimentales de Linux y Windows, los navegadores (Firefox está escrito mayoritariamente en Rust), herramientas de línea de comandos ampliamente utilizadas (ripgrep, fd, bat, exa), y una parte creciente de la infraestructura cloud (AWS, Microsoft y Google utilizan Rust en componentes de rendimiento crítico). Crates.io es el registro central de crates de Rust —el equivalente a PyPI para Python o npm para JavaScript—. Los desarrolladores declaran sus dependencias en Cargo.toml, y Cargo (el gestor de paquetes de Rust) descarga los crates de crates.io y los compila. El ataque comprometió las cuentas de varios mantenedores de crates populares —mediante phishing, credenciales filtradas o compromiso de sus repositorios de GitHub— y publicó nuevas versiones de los crates con los scripts de build modificados. Las versiones maliciosas fueron descargadas por cientos de miles de desarrolladores y organizaciones durante el período en que estuvieron disponibles. La cadena de confianza del ecosistema Rust —basada en la confianza en los mantenedores de crates— resultó ser exactamente tan fuerte como la contraseña más débil de los mantenedores. Y las contraseñas de los mantenedores, como en todos los ecosistemas, son tan fuertes como el último ataque de phishing contra ellos.

Así funciona el ataque: malware build-time que se activa durante la compilación y pasa desapercibido en el código fuente

La técnica de malware build-time funciona así. En Rust, cada crate puede incluir un archivo build.rs —un script que se ejecuta antes de la compilación principal—. Este script se utiliza legítimamente para generar código, detectar configuraciones del sistema, o enlazar con librerías nativas. Pero build.rs también puede hacer cualquier otra cosa: descargar archivos de internet, generar código fuente dinámicamente, o ejecutar comandos del sistema. Los atacantes modificaron build.rs de los crates comprometidos para que, durante la compilación, generara silenciosamente un archivo fuente adicional que contiene el malware y lo incluyera en el binario final. El malware generado es específico de la plataforma de compilación —un troyano de acceso remoto en Windows, una puerta trasera en Linux, un stealer en macOS—. El código fuente del crate en GitHub parece completamente limpio: build.rs tiene una línea adicional que parece inocua, quizás un comando para verificar una ruta de archivo. Pero esa línea activa una cadena de generación de código que produce el malware. Herramientas de análisis estático que escanean el código fuente del crate no detectan nada —el malware no existe hasta el build—. Herramientas de SCA (Software Composition Analysis) que comparan versiones y hashes tampoco lo detectan —la versión maliciosa tiene el mismo código fuente visible que la versión legítima—. Solo un análisis del proceso de build completo, o del binario resultante, revela el malware. Y nadie analiza el proceso de build de sus dependencias. Es el punto ciego perfecto.

El impacto en organizaciones que compilan Rust: desde startups blockchain hasta infraestructura crítica

El impacto afecta a organizaciones de todo el espectro. Startups blockchain que compilan Rust para sus nodos y contratos inteligentes. Equipos de infraestructura que compilan herramientas de línea de comandos para sus servidores. Empresas de ciberseguridad que utilizan herramientas Rust en sus pipelines de análisis. Proyectos open-source que incluyen los crates comprometidos como dependencias transitivas —dependencias de sus dependencias, que heredan sin saberlo—. Un desarrollador que compila una herramienta con un crate comprometido produce un binario infectado. Ese binario se distribuye a los usuarios finales, que lo ejecutan con plena confianza. La infección se propaga a través de la cadena de compilación: el crate malicioso infecta la herramienta, la herramienta infectada se distribuye a los usuarios, los usuarios la ejecutan en sus entornos. Para organizaciones que distribuyen software compilado en Rust, el impacto es una filtración de seguridad masiva —han estado distribuyendo malware a sus clientes sin saberlo—. Para organizaciones que utilizan software Rust de terceros, el impacto es la instalación de puertas traseras en su infraestructura. El coste de un ataque a la cadena de suministro de compilación se mide en la confianza destruida: ¿cómo vuelves a confiar en tus binarios compilados cuando no sabes qué versiones de tus dependencias estaban comprometidas y durante cuánto tiempo?

Cómo MagnoSec audita dependencias de Rust y pipelines de compilación

En MagnoSec, las auditorías de cadena de suministro de software incluyen la evaluación de procesos de compilación y dependencias en todos los ecosistemas, incluido Rust. Analizamos el árbol de dependencias completo: ¿qué crates se utilizan, en qué versiones, con qué dependencias transitivas? Verificamos la integridad de los crates: ¿los checksums coinciden con los publicados? ¿Los crates descargados coinciden con el código fuente en los repositorios de los mantenedores? Revisamos los scripts de build: ¿qué hacen build.rs y los scripts de pre-compilación? ¿Descarga recursos externos? ¿Genera código dinámicamente? ¿Ejecuta comandos del sistema? Implementamos builds reproducibles: compilar el mismo código en dos entornos independientes debe producir binarios idénticos. Si los binarios difieren, algo está mal. Evaluamos el proceso de actualización de dependencias: ¿quién decide cuándo actualizar? ¿Se revisan los cambios entre versiones antes de actualizar? ¿Hay un proceso de aprobación para nuevas dependencias? Y recomendamos la práctica de 'vender' las dependencias (vendoring): descargar y congelar las versiones exactas de las dependencias en el repositorio del proyecto, en lugar de depender de descargas dinámicas del registro en cada build. El vendoring no elimina el riesgo, pero lo convierte en un riesgo auditado y controlado. La promesa de seguridad de Rust se refiere a la seguridad de la memoria. La seguridad de la cadena de suministro es un problema distinto —y no menos importante—. Un lenguaje seguro en memoria con dependencias comprometidas produce binarios igual de peligrosos que un lenguaje inseguro con dependencias limpias. La seguridad del lenguaje no te salva del malware en tus dependencias.

Defensa: verificación de integridad de crates, firma de builds y análisis de dependencias antes de compilar

La defensa contra ataques de cadena de suministro en Rust y otros ecosistemas se construye sobre la verificación y la reproducibilidad. Medida 1: fijar las versiones exactas de las dependencias en Cargo.lock y no actualizar sin revisión. Cada actualización de una dependencia es una oportunidad para introducir malware. Revisa los cambios entre versiones antes de actualizar. Medida 2: verificar la integridad de los crates descargados contra los checksums oficiales y contra el código fuente en los repositorios de los mantenedores. Herramientas como cargo-audit y cargo-vet ayudan a automatizar esta verificación. Medida 3: implementar builds reproducibles y verificar que los binarios producidos en entornos independientes son idénticos. Si un binario difiere, investiga antes de distribuirlo. Medida 4: auditar los scripts de build de todas las dependencias —incluyendo las transitivas—. Un build.rs que descarga archivos de internet o genera código dinámicamente es una bandera roja. Medida 5: para organizaciones que distribuyen software Rust, implementar la firma criptográfica de los binarios publicados y proporcionar a los usuarios mecanismos para verificar las firmas. La confianza en la distribución de software debe ser verificable, no asumida. El ataque a los crates de Rust demuestra que ningún ecosistema es inmune a la cadena de suministro. La pregunta no es si tu ecosistema será atacado —todos lo son—, sino si tienes los controles para detectar el ataque antes de que tus binarios comprometidos lleguen a producción. En seguridad de cadena de suministro, la detección tardía es detección fallida.

Temas tratados

Rust · supply chain · crates · malware · build-time · crates.io · dependencias · compilación

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?