La comprometida Cloudflare convirtió una fuente fiable en un canal de distribución de malware que roba información.

Los atacantes no necesitaron un sitio falso para introducir a los desarrolladores módulos Terraform maliciosos. Personas desconocidas obtuvieron acceso a la infraestructura de Cloudflare que usa Coder, añadieron sus propias direcciones IP al conjunto del registro oficial registry.coder.com y provocaron que el dominio real a veces entregara paquetes modificados con un exfiltrador de secretos.
El ataque duró alrededor de 14 horas el 31 de agosto, desde las 07:35 hasta las 21:45 UTC. Parte de las solicitudes al registro oficial se dirigieron a los servidores de los atacantes, donde había una copia modificada del Coder Registry. Como resultado, un desarrollador podía solicitar la dirección correcta registry.coder.com y aun así recibir un módulo Terraform malicioso. Una comprobación sencilla del dominio o restringir las descargas a una dirección de confianza no protegían frente a ese esquema.
El código malicioso se ejecutaba mediante el bloque de Terraform data "external" "telemetry" y los scripts dlp.sh y dlp-docker.sh. El ladrón buscaba secretos en variables de entorno, archivos de configuración y el historial del terminal. Estuvieron en riesgo las claves de la infraestructura en la nube y de servicios de IA, las credenciales de CI/CD, las claves SSH, los tokens OIDC y otros datos accesibles para los componentes de Coder.
Al ejecutar un módulo infectado durante la compilación del espacio de trabajo, el riesgo aumentaba. El aprovisionador podía obtener el token OIDC del usuario, la clave SSH configurada y tokens de un solo uso de servicios de autenticación externos. Si el aprovisionador funcionaba dentro de coderd, el código malicioso potencialmente también veía la contraseña de la base de datos y otros parámetros del propio Coder. La información recopilada se enviaba a un dominio parecido a la infraestructura del desarrollador, coder-infra[.]com, registrado el 28 de agosto, tres días antes del ataque.
Quedan bajo sospecha las organizaciones que en el periodo de riesgo crearon nuevas plantillas, actualizaron sus versiones, ejecutaron una compilación de prueba o desplegaron espacios de trabajo sin almacenar en caché los módulos Terraform. El almacenamiento en caché está activado por defecto, por lo que las copias seguras guardadas previamente podrían haber protegido parte de las instalaciones.
Coder no puede determinar con precisión a todos los afectados. Los servidores maliciosos pertenecían a los atacantes, por lo que la compañía no dispone de sus registros. Se recomienda a los administradores comprobar DNS, cortafuegos, proxies y los registros de VPC en busca de conexiones con coder-infra[.]com, buscar en los registros del aprovisionador la cadena data.external.telemetry, eliminar módulos sospechosos del caché y cambiar todos los secretos a los que el aprovisionador pudo haber accedido.
La empresa evaluó el incidente como crítico con una puntuación CVSS de 9,0 sobre 10. Las versiones corregidas de Coder recibieron los números 2.37.0, 2.36.4, 2.35.7 y 2.34.9. No se asignó un CVE separado al incidente, ya que no se trata de una vulnerabilidad clásica de software, sino de la compromisión de la infraestructura de distribución de componentes.
Coder afirma que, de momento, no hay indicios de acceso a los datos de clientes que la propia empresa almacena. Sin embargo, el ataque muestra una característica desagradable de la compromromisión de la cadena de suministro: un dominio de confianza y la dirección correcta del registro ya no garantizan que el componente obtenido provenga realmente del servidor del desarrollador.