Ataque dirigido a mantenedores de Rust para colar malware en crates

El equipo de seguridad de crates ha publicado un aviso sobre una campaña en curso contra miembros de rust-lang y propietarios de crates con muchos usuarios. El objetivo no es robar credenciales y marcharse, sino quedarse dentro: comprometer dispositivos y cuentas para usarlos como plataforma desde la que publicar malware en el ecosistema.

Adam Harvey y el equipo de seguridad de crates lo describen así: "Creemos que hay una campaña en curso dirigida a miembros de rust-lang y propietarios de crates populares que intenta comprometer dispositivos y cuentas para usarlos para publicar malware".

El gancho es una videollamada

El vector es de los que funcionan porque no explota nada. Te llega una videollamada por algo positivo: un puesto de trabajo, un proyecto, una oportunidad de contrato. Durante la llamada, el interlocutor necesita que instales algo —un códec de audio que supuestamente falta, por ejemplo— o que ejecutes un comando, muchas veces colocándolo antes en el portapapeles para que solo tengas que pegarlo. A partir de ahí, la máquina del mantenedor es del atacante, y con ella sus credenciales de publicación.

No es teoría. El mes pasado este mismo truco se usó en un ataque de cadena de suministro que consiguió colar código malicioso en el crate arrayref, entre otros. El aviso enlaza el anuncio oficial del equipo de Rust y el análisis del incidente de arrayref de agosto.

Toda dependencia es una persona

La parte incómoda es que esto no se arregla con un parche. Cualquier programa que dependa de open source —es decir, prácticamente todo el software que se ejecuta hoy— arrastra una red de personas con permisos de publicación sobre alguno de los paquetes de su árbol de dependencias. Cada una de esas cuentas es una entrada posible, y el atacante solo necesita que una ceda. En un proyecto con cientos de dependencias transitivas, la superficie no la forman los mantenedores de las librerías que conoces, sino los de las que ni sabrías nombrar.

Como defensa inmediata queda poco más que retrasar la adopción. La idea de las dependency cooldowns es dejar pasar unos días desde que se publica una versión nueva antes de subirla, con la esperanza de que alguien con más ojos la haya visto antes y el paquete malicioso ya esté señalado cuando te toque. No evita el ataque, pero reduce la ventana en la que un release envenenado se propaga a toda la red de consumidores. Quien tenga pipelines que actualizan dependencias automáticamente en cuanto aparece una versión debería revisar cuánto margen está dando ese automatismo.

Queda por ver si el equipo de crates toma medidas estructurales sobre las cuentas de publicación —segundo factor obligatorio, tokens con alcance limitado, ventanas de bloqueo tras cambios de credenciales— o si el aviso se queda en una advertencia. Mientras tanto, el patrón del ataque conviene tenerlo presente más allá de Rust: la videollamada con excusa laboral es perfectamente trasladable a npm, PyPI o cualquier registro donde publicar tenga consecuencias.