El gusano que se cuela por el código que no escribiste tú

Aquí va una verdad incómoda del software moderno: casi nada de lo que usas lo ha escrito quien crees. Cuando un programador construye una aplicación, no la teje desde cero. Ensambla cientos, a veces miles, de piezas de código abierto hechas por desconocidos de todo el mundo. Es lo que hace que el software avance tan rápido… y también es su talón de Aquiles. Un gusano reciente llamado ChainDrop acaba de demostrar, otra vez, por qué.

Qué ha pasado

A principios de agosto, alguien se hizo con la cuenta del mantenedor de unos paquetes muy populares del ecosistema de JavaScript (la familia de keyv, herramientas que usa medio internet sin saberlo). Con ese acceso, publicó versiones envenenadas de esos paquetes. En cuestión de horas, el veneno se había extendido a cientos de paquetes con, entre todos, más de 2.000 millones de descargas al mes.

Y lo verdaderamente peligroso no es el número. Es cómo se extendió.

La palabra clave: "gusano"

En seguridad, un gusano es un tipo de programa malicioso con una propiedad que da escalofríos: se copia a sí mismo y se propaga solo, sin que nadie lo pilote. ChainDrop es exactamente eso, aplicado a la cadena de suministro del software.

El mecanismo es tan elegante como demoledor:

1. Instalas un paquete infectado. Al ejecutar el típico npm install, se dispara un pequeño script oculto que corre automáticamente, sin preguntarte nada.
2. Te roba las llaves. Ese script rebusca en tu equipo (o en tu sistema de compilación automática) y se lleva tus credenciales: los tokens con los que publicas paquetes, tus claves de GitHub, de la nube, de todo.
3. Se copia a lo tuyo. Con esos tokens robados, publica versiones infectadas de todos los paquetes que tú mantienes. Y ahora cada persona que instale los tuyos empieza el ciclo de nuevo.

No necesita un servidor central que lo dirija ni un humano dándole al botón. Se enciende solo con cada instalación. Es un virus, en el sentido más literal.

Por qué funciona tan bien

Hay tres detalles que lo hacen especialmente difícil de parar:

• Llega firmado y "de fábrica". Como el veneno se publica a través de las tuberías automáticas legítimas del mantenedor (sus pipelines de compilación), las versiones infectadas salen con firmas digitales válidas. Para tu ordenador, parece una actualización de lo más normal.
• La confianza es automática. Casi nadie revisa el código de las 800 dependencias que arrastra su proyecto. Instalas una, y con ella vienen todas las suyas.
• Un eslabón basta. No hace falta reventar a las grandes tecnológicas. Basta con colarse en una pieza pequeña de la que, sin saberlo, dependen todas.

Lo que se aprende (y otra vez, lo básico)

Da un poco de rabia, pero la moraleja vuelve a ser la de siempre: lo que abre la puerta es lo aburrido sin hacer. Aquí, el gusano solo se propaga cuando encuentra un token de publicación sin segundo factor. Es decir, la misma historia de tantas brechas: si esas cuentas de mantenedor hubieran tenido 2FA obligatorio, el incendio se habría quedado en chispa.

Si escribes código, hay cosas concretas que reducen mucho el riesgo:

• Fija tus dependencias. Usa un lockfile y versiones exactas, para que "actualizar" no signifique tragarte a ciegas lo último que se publicó hace cinco minutos.
• Desconfía de los scripts de instalación. Muchos gestores permiten instalar sin ejecutar los scripts automáticos (--ignore-scripts). Ese pequeño hábito corta de raíz a gusanos como este.
• Menos dependencias, menos superficie. Cada paquete que añades es alguien más en quien confías. ¿De verdad necesitas una librería para tres líneas de código?
• 2FA en las cuentas que publican, y credenciales de compilación aisladas y de mínimo privilegio: que un token robado no pueda tocarlo todo.

El fondo del asunto

El software que usamos es una torre altísima construida sobre la confianza entre desconocidos que colaboran gratis. Es una de las cosas más bonitas que ha hecho la tecnología… y también la que un gusano como ChainDrop aprovecha sin piedad. La lección no es "el código abierto es peligroso" (no lo es más que el cerrado, y encima puedes auditarlo). La lección es que esa torre hay que cuidarla: mirando qué metemos, echando el cerrojo del 2FA y no ejecutando a ciegas todo lo que descargamos.

Porque, una vez más, casi nadie fuerza la cerradura. Se cuelan por la pieza que nadie estaba vigilando.