Un ataque coordinado a la cadena de suministro ha afectado a varios paquetes de Rust de uso generalizado, lo que ha generado preocupación entre los desarrolladores y proyectos cuyas cadenas de dependencias incluyen componentes asociados al ecosistema de Solana. Investigadores de seguridad de SlowMist, Socket y StepSecurity informaron que versiones maliciosas afectaron a arrayref@0.3.10, internment@0.8.7 y append-only-vec@0.1.9.

Las versiones comprometidas introdujeron una dependencia con nombre similar (typosquatting) que se asemejaba al paquete legítimo proc-macro1, cuyo script de compilación descargaba y ejecutaba una carga remota durante las compilaciones de Cargo. Como resultado, los desarrolladores y los sistemas de integración continua (CI) podrían haber quedado expuestos simplemente al compilar un proyecto que dependiera de una de las versiones afectadas. Según la información compartida por @WuBlockchain en X, el equipo de seguridad de Rust eliminó las versiones maliciosas y bloqueó la cuenta del mantenedor afectado.

Paquetes maliciosos introducidos a través de la cadena de dependencias

El incidente se centra en el ecosistema de paquetes de Rust, en el que los desarrolladores suelen depender de crates de terceros para aportar funcionalidad a sus aplicaciones y proyectos de software. En este caso, los investigadores identificaron versiones maliciosas de tres crates: arrayref@0.3.10, internment@0.8.7 y append-only-vec@0.1.9.

Las versiones maliciosas contenían una dependencia diseñada para asemejarse al paquete legítimo proc-macro1. Esta técnica, conocida como typosquatting, busca que un paquete malicioso parezca similar a una dependencia legítima. Es una táctica recurrente en los registros de código abierto, incluidos npm y PyPI de Python, donde nombres similares se han utilizado repetidamente para introducir código malicioso mediante actualizaciones rutinarias de dependencias.

El ataque adquirió particular gravedad porque la dependencia maliciosa incluía un script de compilación capaz de descargar y ejecutar una carga remota cuando se compilaba el paquete afectado. Por lo tanto, el riesgo de seguridad no se limitaba necesariamente a los usuarios que instalaban o ejecutaban manualmente un programa evidentemente sospechoso: una estación de trabajo de desarrollador o un entorno de CI podía verse afectado como parte del proceso normal de compilación de software.

El proceso de compilación creó un riesgo de seguridad potencial

Cargo es el gestor de paquetes y el sistema de compilación de Rust, y los desarrolladores lo utilizan de forma rutinaria para obtener dependencias y compilar proyectos. El ataque reportado explotó ese flujo de trabajo. Dado que Cargo ejecuta automáticamente el script de compilación de un crate como parte de la compilación, dicho script se ejecuta con los permisos del usuario o de la cuenta de CI que realiza la compilación.

Cuando se compilaba una dependencia afectada, el script de compilación malicioso podía descargar y ejecutar una carga remota. Esto creó una vía potencial para que un atacante ejecutara código en la máquina de un desarrollador o en un host de CI.

Los sistemas de CI son especialmente importantes en el desarrollo de software moderno porque compilan, prueban e implementan código de manera automática. Un entorno de compilación comprometido puede, por lo tanto, presentar riesgos que van más allá de una sola estación de trabajo de desarrollador, ya que las máquinas de compilación y las estaciones de trabajo suelen almacenar credenciales como tokens de API, claves de despliegue y material de firma. Por esa razón, los equipos de seguridad suelen considerar la ejecución de código durante la compilación como motivo para rotar cualquier secreto presente en los sistemas afectados.

El incidente pone de relieve el desafío de seguridad más amplio asociado a las cadenas de suministro de software, donde el código malicioso puede ingresar a un proyecto de manera indirecta a través de dependencias que los desarrolladores pueden no haber escrito ni revisado ellos mismos.

Las cadenas de dependencias relacionadas con Solana atraen atención

El crate arrayref se utiliza ampliamente en el ecosistema de Rust y aparece en cadenas de dependencias que involucran componentes asociados con Solana. El software de validadores de Solana y gran parte de sus herramientas circundantes están escritos en Rust, razón por la cual crates de propósito general como arrayref pueden aparecer dentro de árboles de dependencias relacionados con Solana, aunque los crates en sí no sean específicos de blockchain. Sin embargo, la presencia de un crate afectado dentro de una cadena de dependencias no significa que los proyectos posteriores relacionados con Solana hayan sido comprometidos.

Esta distinción es importante porque el software de código abierto suele depender de múltiples capas de dependencias. Un paquete vulnerable o comprometido puede aparecer en algún punto del árbol de dependencias de un proyecto sin que ello derive necesariamente en el compromiso exitoso de la aplicación o la red final.

Por ello, los investigadores de seguridad distinguen entre la exposición a una dependencia maliciosa y la evidencia de que el código malicioso se ejecutó realmente dentro de un proyecto o entorno posterior específico. El incidente reportado establece que las versiones afectadas contenían código malicioso, pero no establece que todos los proyectos que utilizaban dependencias relacionadas hayan sido comprometidos.

El equipo de seguridad de Rust elimina las versiones maliciosas

El equipo de seguridad de Rust respondió eliminando las versiones maliciosas y bloqueando la cuenta del mantenedor asociada con los paquetes. Según la información reportada, es probable que la máquina del mantenedor o sus credenciales de publicación hubieran sido comprometidas.

Una cuenta de publicación comprometida puede representar un riesgo significativo en los ecosistemas de código abierto, porque los atacantes podrían distribuir software malicioso bajo la identidad de un mantenedor legítimo. La eliminación de las versiones afectadas limita su distribución posterior a través del ecosistema de paquetes, mientras que el bloqueo de la cuenta impide que se publiquen versiones adicionales mediante las credenciales comprometidas. Los avisos de seguridad sobre crates de Rust comprometidos se registran en la base de datos de avisos RustSec, mantenida por la comunidad, uno de los canales que los desarrolladores pueden monitorear junto con el registro crates.io.

El incidente también demuestra la importancia de monitorear las dependencias y revisar las actualizaciones inesperadas de paquetes, en particular cuando los proyectos dependen de árboles de dependencias grandes y complejos.

Implicaciones más amplias para los desarrolladores de Rust

Los ataques a la cadena de suministro se han convertido en una preocupación de seguridad significativa en todo el desarrollo de software, porque se dirigen a la infraestructura y las dependencias utilizadas para construir aplicaciones en lugar de atacar directamente la aplicación final. En este caso, el código malicioso estaba incrustado en versiones de paquetes y se activaba durante el proceso de compilación. Este patrón tiene precedentes bien documentados, como la puerta trasera de XZ Utils divulgada en marzo de 2024, en la que un atacante aprovechó la posición de un mantenedor en una biblioteca de compresión de código abierto fundamental, y el compromiso del paquete @solana/web3.js en npm en diciembre de 2024, que afectó a una biblioteca de JavaScript ampliamente utilizada por los desarrolladores de Solana. Ambos episodios, como este, muestran cómo la confianza en una cuenta de mantenedor o en la identidad de un paquete puede convertirse en una superficie de ataque.

Los desarrolladores que utilizan proyectos de Rust pueden reducir su exposición a incidentes similares monitoreando las versiones de las dependencias, revisando los cambios inesperados y utilizando herramientas de seguridad capaces de identificar paquetes sospechosos o comportamientos anómalos de dependencias. En el caso específico de este incidente, ello se traduce en buscar las tres versiones afectadas en archivos de bloqueo como Cargo.lock, revisar los registros de CI y de compilación en busca de actividad de red saliente inesperada y rotar las credenciales en cualquier máquina donde se hayan compilado las versiones afectadas. Las organizaciones que dependen de entornos de CI automatizados también deben considerar la seguridad de su infraestructura de compilación, porque las dependencias maliciosas pueden potencialmente ejecutar código antes de que una aplicación sea implementada.

La respuesta del ecosistema de Rust demuestra la importancia de la vigilancia de seguridad coordinada y la eliminación rápida de paquetes comprometidos. Si bien los crates afectados tienen vínculos con cadenas de dependencias que involucran componentes relacionados con Solana, la información disponible no establece que Solana en sí o proyectos posteriores específicos hayan sido comprometidos. El incidente sirve más bien como un recordatorio de que las dependencias de código abierto de uso generalizado pueden convertirse en un vector de ataque potencial cuando se comprometen las credenciales de publicación o los entornos de los mantenedores.

Fuente: Hokanews