Coder reveló una intrusión en la infraestructura de su registro de software registry.coder.com, que permitió a un atacante añadir servidores no autorizados a la infraestructura que gestiona a través de Cloudflare. Como resultado, algunas solicitudes de descarga fueron dirigidas a los servidores del atacante en lugar de a los servidores legítimos de Coder, lo que provocó la entrega de versiones maliciosas de módulos de Terraform a un grupo de usuarios.
La ventana de distribución de los archivos maliciosos tuvo lugar el 31 de agosto, entre las 07:35 y las 21:45 UTC, según informó Coder. Los módulos modificados estaban dirigidos a entornos de ejecución de herramientas de aprovisionamiento, ya que contenían código que funcionaba como un ladrón de información al ejecutarse en los dispositivos afectados.
¿Qué datos estuvieron en riesgo?
Los módulos maliciosos buscaron una amplia variedad de secretos y credenciales presentes en el entorno del usuario, entre ellos:
- Variables de entorno y secretos de los procesos de Provisioner.
- Claves de API de la infraestructura en la nube y de herramientas de inteligencia artificial.
- Credenciales de sistemas CI/CD.
- Secretos presentes en archivos de configuración y en el historial de la terminal.
- Tokens OIDC y claves SSH configuradas, además de tokens de autenticación externa de un solo uso.
- Contraseñas de la base de datos de Coder y otros secretos, cuando Provisioner se ejecuta dentro de coderd.
Los datos recopilados se enviaron al dominio similar coder-infra[.]com. Coder recomienda a los usuarios potencialmente afectados rotar lo antes posible todos los secretos incluidos en la lista.
Pasos de verificación y mitigación
Antes de actualizar a las versiones corregidas 2.37.0, 2.36.4, 2.35.7 o 2.34.9, Coder solicitó revisar los registros de los cortafuegos, del proxy y del DNS, así como los flujos de VPC, en busca de conexiones con el dominio malicioso. Los desarrolladores también deberían buscar data.external.telemetry en los registros de Provisioner, identificar los módulos descargados durante la ventana de exposición y eliminar de la caché los paquetes que posiblemente hayan sido manipulados.
Coder también proporcionó una consulta SQL que ayuda a identificar los módulos almacenados en caché y las versiones de las plantillas que podrían estar afectadas.
¿Por qué importa este compromiso?
El riesgo no se limita a un paquete de software publicado de forma maliciosa, sino que se extiende a un punto de distribución de confianza del que dependen los desarrolladores para crear plantillas de entornos de trabajo e infraestructura. Además, la naturaleza de los secretos a los que apuntaban los módulos incluye claves de servicios en la nube, herramientas de inteligencia artificial y entornos CI/CD, lo que hace que el incidente sea directamente relevante para los equipos de desarrollo, plataformas y seguridad.
Coder afirmó que los tokens de actualización no se pasaron a Provisioner y que no encontró pruebas de que los datos de los clientes que conserva se hubieran visto afectados. Sin embargo, reconoció al mismo tiempo que la infraestructura utilizada por el atacante se encuentra fuera de su control, por lo que no dispone de registros importantes ni puede determinar de forma concluyente todos los despliegues que fueron comprometidos. Esta laguna hace que la rotación de secretos y la verificación independiente de los registros sean medidas necesarias incluso en los casos en los que no aparezcan pruebas directas de filtración.