Coder ha confirmado que su infraestructura de registro fue comprometida por un atacante que consiguió inyectar servidores no autorizados en el sistema que distribuye módulos Terraform a los usuarios de la plataforma. Según recoge BleepingComputer, el ataque afectó a registry.coder.com, el sitio de alojamiento de paquetes que los desarrolladores usan para construir sus plantillas de espacios de trabajo.
Coder permite a organizaciones ofrecer a sus desarrolladores entornos de desarrollo en la nube autoalojados y seguros, usados para construir y desplegar software, incluidas aplicaciones de inteligencia artificial. El proyecto lo utilizan organizaciones privadas y gubernamentales de peso: Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, el gobierno de Estados Unidos y empresas del sector de defensa figuran entre sus usuarios.
El atacante entró por Cloudflare y suplantó los servidores legítimos
Aunque el registro de Coder funciona detrás de Cloudflare, el atacante logró acceder a la infraestructura subyacente y añadió direcciones IP no autorizadas al conjunto de servidores del registro. El resultado fue que Cloudflare enrutó parte de las peticiones al registro hacia los servidores del atacante en lugar de a los legítimos de Coder, entregando así ficheros maliciosos a un subconjunto de usuarios.
«Un actor malicioso no identificado obtuvo acceso a la infraestructura de Cloudflare de Coder y añadió direcciones IP no autorizadas al conjunto usado para el registro de módulos de Coder», recoge el aviso de la compañía citado por la fuente. «Estas direcciones IP no autorizadas alojaban una versión del registro de Coder que contenía artefactos con código malicioso.»
La ventana de entrega maliciosa duró más de catorce horas
Coder ha precisado que la ventana durante la que se sirvieron los artefactos maliciosos fue entre las 07:35 y las 21:45 UTC del lunes 31 de agosto. Durante ese tramo, los servidores del atacante distribuyeron versiones modificadas de módulos Terraform, que son paquetes de instrucciones listos para usar para crear y configurar infraestructura de computación.
Esa franja horaria equivale a algo más de catorce horas continuas de exposición, tiempo suficiente para que cualquier equipo que ejecutara despliegues automatizados durante esa jornada descargara, sin saberlo, una versión modificada de sus módulos habituales. Es precisamente esa ventana concreta, y no una fecha posterior, la que cada organización usuaria tiene que revisar en sus propios registros.
Según Coder, los módulos modificados actuaban como ladrones de información en los equipos infectados, buscando credenciales y otros datos sensibles. La información recopilada se exfiltraba hacia el dominio suplantador «coder-infra[.]com».
Qué debe hacer quien haya usado el registro durante esas horas
Coder recomienda a los usuarios potencialmente afectados rotar de inmediato todos los secretos que pudieran haberse expuesto. Antes de actualizar a una de las versiones parcheadas —2.37.0, 2.36.4, 2.35.7 y 2.34.9—, la compañía aconseja revisar los registros de firewall, proxy, DNS y flujo de VPC en busca de conexiones hacia coder-infra[.]com.
También se recomienda a los equipos de desarrollo buscar en los registros del provisioner referencias a data.external.telemetry, identificar qué módulos se descargaron durante la ventana de exposición y purgar los paquetes en caché que puedan ser maliciosos. Para facilitar esta comprobación, Coder ha compartido una consulta SQL que permite identificar módulos en caché y versiones de plantilla potencialmente afectados.
Este último punto es el que más importa a quien administra despliegues de Coder en producción: no basta con parchear, hay que auditar retroactivamente lo que se descargó durante ese día concreto, porque el problema no fue una vulnerabilidad de código sino una entrega de contenido malicioso disfrazado de módulo legítimo. Cualquier organización que gestione infraestructura sensible a través de plantillas de Coder debería tratar como comprometido cualquier secreto usado en pipelines que corrieran entre esas fechas, y no dar por buena la ausencia de alertas si no ha revisado antes los registros indicados.
Coder dice no tener acceso a todos los registros del ataque
El proyecto ha señalado que los tokens de refresco no se pasaron al provisioner y que no hay evidencia de impacto en los datos de clientes que mantiene la compañía. Sin embargo, como la infraestructura del atacante está fuera de su control, Coder no tiene acceso a los registros cruciales y no puede identificar de forma concluyente todos los despliegues comprometidos.
Esa limitación es la que obliga a cada organización usuaria a hacer su propia comprobación con las herramientas que Coder ha publicado, en lugar de esperar una confirmación centralizada de si estuvo o no afectada.
Escrito por Eloy Andrade
