Código malicioso viajó en paquetes oficiales de Red Hat para robar claves

Durante un tiempo, algunas de las piezas de software que se distribuyen bajo el nombre de Red Hat trabajaron en silencio contra quienes las instalaban. Dentro de más de 30 paquetes de la colección pública @redhat-cloud-services de la compañía había un pequeño script preparado para ejecutarse en el instante en que un desarrollador instalaba cualquiera de ellos. Estaba configurado como un paso preinstall, una de esas tareas automáticas que la herramienta npm lanza por su cuenta antes de que se cargue una sola línea del software real. Su tarea era buscar contraseñas y, después, propagarse.

Red Hat no fabrica aplicaciones que la mayoría de la gente abra por su nombre, pero su código sostiene buena parte de lo que usamos a diario: los paneles en la nube por los que entra un banco, los sistemas sobre los que funcionan hospitales y administraciones públicas, las herramientas con las que otras empresas construyen sus propios productos. Cuando un código con esa etiqueta se vuelve hostil, el radio de impacto no es una aplicación. Es todo lo que se levanta encima.

El script oculto salió a buscar las llaves que abren la informática moderna. Según la firma de seguridad StepSecurity, la primera en alertar sobre los paquetes, se llevó tokens de acceso de Amazon Web Services, Google Cloud, Microsoft Azure, Kubernetes, HashiCorp Vault, la propia npm y el servicio de automatización CircleCI, además de los secretos guardados dentro de las cadenas de compilación de GitHub. Para alcanzarlos leía la memoria en bruto del proceso de compilación en marcha, una técnica que esquiva las protecciones pensadas para que los secretos no aparezcan en los registros.

Lo que convierte un robo de datos corriente en algo más parecido a un brote es lo que el código hacía a continuación. Con los tokens de publicación de npm robados, intentaba subir versiones recién manipuladas de cualquier otro paquete al que la cuenta secuestrada tuviera acceso, usando un parámetro que anula la verificación en dos pasos que normalmente lo impediría. Un robo que se copia a sí mismo no se queda con sus primeras víctimas. Viaja por la misma confianza sobre la que se sostiene todo el sistema.

En los equipos de los propios desarrolladores el código fue más lejos: dejaba instrucciones dentro de la configuración de tareas de Visual Studio Code y de los ajustes de Claude Code, el asistente de programación con inteligencia artificial, para seguir ejecutándose mucho después de terminar la instalación. Quienes más probablemente instalan estos paquetes, los ingenieros que mantienen el software de los demás, eran también aquellos cuyos portátiles se convertían en punto de entrada.

El detalle más incómodo es de dónde salieron las versiones envenenadas. Los desarrolladores de Red Hat, que reconocieron el problema en el repositorio público del proyecto, y los investigadores que diseccionaron el código coinciden en que esas versiones se publicaron a través de la propia cadena de publicación automática de Red Hat, la maquinaria que toma el código de sus repositorios y lo envía al mundo. Los atacantes no suplantaron a Red Hat. Durante un tiempo, pudieron publicar como Red Hat. El sello de confianza y aquello que se confiaba se separaron.

No es la primera vez que la cadena de suministro del software libre se convierte en una vía de reparto. Extensiones de navegador manipuladas y cuentas de desarrolladores secuestradas han aparecido una y otra vez durante la primavera, todas aprovechando la misma costumbre: el software moderno se ensambla con miles de componentes gratuitos que nadie escribe desde cero. Lo que hace que este caso pese más es el nombre en la caja. La razón misma de tomar código de un proveedor como Red Hat, y no de un colaborador anónimo, es que ese nombre debería ser la garantía.

Conviene precisar qué no significa este incidente. De momento no hay indicios de que se infectaran dispositivos de usuarios corrientes, ni de que se vulneraran los productos empresariales de pago de Red Hat o los sistemas en producción de sus clientes. Las versiones maliciosas apuntaron al territorio intermedio del desarrollo, los servidores de compilación automáticos y los equipos de los ingenieros, y muchos de los paquetes afectados son herramientas de interfaz y de desarrollo, no el núcleo de ningún servicio en funcionamiento. El cuadro además sigue cambiando, y el número exacto de paquetes contaminados se ha movido a medida que Red Hat y los investigadores externos repasan la lista. El daño que más importa, las credenciales robadas, permanece invisible hasta que alguien las usa.

Red Hat ha ido retirando las versiones maliciosas y las publicaciones comprometidas se están eliminando de npm. A quien las haya instalado en la ventana afectada se le pide que dé por quemado cada token que la compilación pudiera ver y que lo renueve. La divulgación llegó a comienzos de junio, y la limpieza durará más que los titulares. El problema de fondo durará más que la limpieza: internet se ensambla, a toda velocidad, con millones de piezas pequeñas mantenidas por gente que nunca conoceremos y, cada vez más, por sistemas automáticos que pueden ser secuestrados para firmar esas piezas en su lugar.

Etiquetas: ciberseguridad, malware, npm