El ataque ya no va al repositorio: va al mantenedor y empieza con una oferta de trabajo

El proyecto Rust ha avisado de que alguien está yendo a por sus colaboradores y a por los dueños de paquetes. No contra el código: contra las personas que tienen permiso para publicar. El objetivo final es el registro de paquetes, y el camino es una oferta de trabajo.

Qué ha pasado

Adam Harvey, ingeniero centrado en seguridad, lo ha contado en el blog oficial de Rust. El patrón le recuerda a las campañas de falsos reclutadores atribuidas a Corea del Norte: se concierta una videollamada por algo que suena bien —un puesto, un contrato, colaborar en un proyecto— y la llamada es el vehículo. O te hacen instalar algo (el clásico códec de audio que supuestamente falta para que te oigan), o te hacen ejecutar un comando que ya venía copiado en el portapapeles.

Lo que hace que funcione no es la técnica, es el decorado:

Estos atacantes se montan perfiles de empresa nuevos pero con pinta de legítimos, incluida una presencia creíble en LinkedIn, para aguantar una revisión rápida.

Y una revisión rápida es lo único que casi nadie se salta.

El aviso llega después de un verano movido. En junio hubo acercamientos con un supuesto fondo de inversión con sede en Singapur; uno de los mantenedores que publica en crates.io tiró del hilo y descubrió que la empresa que decía reclutarle ya no existía. Aun así, el primer contacto colaba, y estuvo a un paso de acabar con un troyano de acceso remoto —un RAT: control remoto de tu máquina— dentro de su equipo.

Eso encaja con el aviso conjunto que publicaron la semana anterior agencias de Australia, Alemania, Japón y Estados Unidos: operadores norcoreanos habrían comprometido más de treinta mil dispositivos usando entrevistas falsas, con un robo de más de diez millones de dólares.

Y en paralelo, en agosto, el ecosistema ya se comió un ataque de cadena de suministro: se publicaron versiones maliciosas del crate arrayref, que descargaban malware en la máquina de quien compilaba. arrayref acumula doscientos cuarenta y cinco millones de descargas en su historia. Las versiones envenenadas estuvieron disponibles menos de dos horas, y todo apunta a credenciales robadas de un mantenedor, no a alguien del proyecto haciendo el mal a propósito.

Por qué importa si tú escribes software

Junta las dos piezas y el dibujo queda claro: el eslabón débil de un paquete con cientos de millones de descargas es un portátil. Uno. El de una persona que, además de mantener la librería, tiene ahí las claves SSH, la sesión del registro y el token de publicación.

Esto me toca de lleno porque yo soy exactamente eso: una persona. Y probablemente tú también, aunque trabajes en un equipo grande, porque la cuenta que sube la release suele ser de alguien concreto.

Cosas que cambiaría hoy mismo, del lado del que publica:

• Nada de código de terceros en la máquina que publica. Si te mandan un repo para "una prueba técnica", se abre en una máquina virtual desechable o en un contenedor sin credenciales dentro. Un npm install o un cargo build ejecuta código arbitrario, y la prueba técnica es el vector.
• El portapapeles no se pega a ciegas en la terminal. Ese truco funciona porque el comando visible y el comando copiado no son el mismo. Pégalo primero en el editor, míralo, y luego decides.
• Ninguna llamada legítima necesita que instales un códec. Si la plataforma te pide un binario para que te oigan, la reunión se ha terminado. Videollamadas por herramientas conocidas y ya.
• Tokens de publicación con el mínimo alcance y caducidad, segundo factor en la cuenta del registro y, cuando se pueda, publicación desde CI con identidad verificada en lugar de un token eterno guardado en tu ~.

Y del lado del que consume dependencias, que somos todos:

• Instalaciones reproducibles en CI. Compilar con el fichero de bloqueo tal cual y fallar si no cuadra. Si tu pipeline resuelve versiones nuevas por su cuenta, una ventana de dos horas te alcanza.
• Pregúntate ahora si sabrías responder a esto: ¿tu CI tiró de esa dependencia en esa franja concreta del mes de agosto? Si la respuesta es "habría que mirarlo", el problema no es el crate, es tu trazabilidad. Guarda los logs de resolución y ten un inventario de lo que entra en cada build.
• Cuarentena para versiones nuevas de dependencias pequeñas y muy usadas. Las librerías minúsculas son el mejor objetivo: nadie lee el diff de un paquete de doscientas líneas que lleva años sin sorpresas.
• Comprobación automática de avisos de seguridad en cada build, no una vez al trimestre.

La lección de fondo: la seguridad de tu cadena de suministro depende de la higiene operativa de gente que no conoces y que no te debe nada. No puedes auditarla. Lo único que puedes hacer es reducir tu ventana de exposición y saber, con logs, qué entró y cuándo.

Qué NO cambia

Seamos honestos con los límites, porque esto se está contando como "problema de Rust" y no lo es.

No es un fallo de Rust. El mismo guion se ha usado contra npm, contra PyPI y contra extensiones de editores. La seguridad de memoria del lenguaje no te protege de un ingeniero cansado que pega un comando a las once de la noche. Son capas distintas del problema.

Las cifras grandes no son de Rust. Los más de treinta mil dispositivos y los más de diez millones de dólares del aviso internacional corresponden a campañas amplias contra todo tipo de perfiles técnicos, no al ecosistema de crates. Mezclarlas es hacer titular.

No hay indicios de un ecosistema comprometido a lo grande. El caso de agosto fueron credenciales robadas y la ventana fue corta. Eso no lo hace inofensivo, pero tampoco es "el registro está tomado".

El segundo factor no es una bala de plata. Si el troyano ya está dentro, la sesión abierta también es suya. El 2FA sube el coste de robar la cuenta desde fuera; no salva una máquina infectada.

Y el contrapeso incómodo: no puedes tratar cada mensaje de un reclutador como un ataque, porque así se pierden oportunidades reales. La recomendación sensata es la que da Harvey: mirar con lupa el contacto no solicitado aunque parezca legítimo, y llevar la conversación a plataformas de confianza. Eso, más no ejecutar nunca nada de un desconocido en la máquina que tiene tus llaves, cubre casi todo.

Cualquier duda me dices y lo vemos.

Un saludo, Vicente.