Masivo ataque a la CI de GitHub roba secretos de miles de repositorios

A partir del martes, un ciberataque coordinado aprovechó credenciales robadas de 4.837 cuentas de GitHub para infiltrarse en las cadenas de suministro de software. Los atacantes implantaron código malicioso diseñado para robar secretos y credenciales de la nube de los flujos de trabajo de Integración Continua (CI) en al menos 1.806 repositorios. Esta campaña pone de manifiesto los graves riesgos asociados con las identidades de desarrolladores comprometidas y las pipelines de compilación automatizadas.

Qué ocurrió

El ataque comenzó cuando el atacante abrió solicitudes de pull de prueba tituladas "docs: dependency audit notes" desde ramas llamadas "wfx-docs". Estas pruebas se desplegaron en 61.764 repositorios para verificar el acceso de escritura. En los repositorios donde se concedió dicho acceso, el atacante inyectó un ladrón de secretos en la configuración de CI. Según Aikido Security, el ladrón estaba diseñado para cosechar secretos, credenciales de la nube y tokens de tiempo de ejecución accesibles desde el entorno del flujo de trabajo. Investigadores de SafeDep identificaron 8.093 repositorios que recibieron commits maliciosos entre las 12:46 UTC del martes y las 04:36 UTC del día siguiente, señalando que el número real es probablemente mayor, ya que su análisis solo cubrió las ramas predeterminadas públicas.

Una vez ejecutado el ladrón, este solía exfiltrar datos mediante HTTP POST a direcciones IP específicas o a través de chats de Telegram. El atacante a menudo revertía los cambios en cuestión de minutos y eliminaba los registros de ejecución del flujo de trabajo para ocultar las evidencias. Sin embargo, en muchos casos el daño ya estaba hecho. El ladrón apuntaba a una amplia variedad de credenciales, incluidos secretos de GitHub Actions, tokens OIDC y claves para AWS, Azure, GCP y Kubernetes. En algunos casos, el malware se introdujo a través de hooks postinstall de npm, lo que significa que cualquier desarrollador que ejecutara "npm install" sobre el commit afectado podría haber comprometido potencialmente su máquina local.

Detalles clave

• Escala: Se comprometieron 4.837 cuentas de GitHub, enviándose solicitudes de pull de prueba a 61.764 repositorios.
• Impacto: El ladrón se ejecutó en al menos 1.806 repositorios, encontrándose commits maliciosos en más de 8.093 repositorios.
• Método: Los ataques comenzaron con solicitudes de pull tituladas "docs: dependency audit notes" desde ramas "wfx-docs".
• Persistencia: El malware crea puertas traseras en AWS y Azure que sobreviven a la rotación de credenciales, como reescribir políticas de confianza.
• Indicadores: Busque ramas como "wfx-docs", "chore/[a-z0-9]{8}" o mensajes de commit como "ci: refresh build cache".
• Paquetes afectados: Se encontraron versiones maliciosas en el paquete Packagist digitalelvis/neuronai-studio v3.14.3 y varios módulos Go.

Contexto

Los sistemas de Integración Continua (CI), como GitHub Actions, automatizan el proceso de compilar, probar y desplegar código. Para funcionar, estos flujos de trabajo suelen requerir acceso a credenciales sensibles, como claves de proveedores de nube o contraseñas de bases de datos. Estos secretos se almacenan en la configuración del repositorio y se inyectan en el entorno del runner durante la ejecución. Si un atacante obtiene acceso de escritura a un repositorio, puede modificar los archivos del flujo de trabajo para incluir pasos maliciosos que impriman o envíen estos secretos a un servidor externo.

Este ataque explota específicamente los tokens OpenID Connect (OIDC), que permiten a los runners de CI autenticarse con proveedores de nube sin almacenar secretos de larga duración. Al robar estos tokens de corta duración, el atacante puede solicitar nuevas sesiones a los proveedores de nube. Más peligrosamente, el ladrón incluye lógica para crear puertas traseras persistentes, como añadir credenciales de identidad federada en Azure o crear claves de acceso de larga duración en AWS. Esto asegura que el atacante mantenga el acceso incluso después de que los tokens comprometidos iniciales sean rotados.

Por qué importa

Para los equipos que ejecutan su propio software o gestionan infraestructura autoalojada, este incidente subraya la importancia crítica de asegurar las pipelines de CI/CD. Muchas organizaciones asumen que, debido a que su código es privado o sus runners están autoalojados, son inmunes a tales ataques. Sin embargo, el ladrón fue diseñado para apuntar a repositorios privados y runners autoalojados, extrayendo credenciales de los metadatos de la instancia y los estados de los contenedores Docker. Si su pipeline de CI tiene permisos amplios, un único commit comprometido puede llevar a la toma de control total de una cuenta en la nube.

Los mecanismos de persistencia utilizados por el atacante dificultan la remediación. Simplemente rotar los secretos es insuficiente si el atacante ha modificado las políticas de identidad en la nube. Los equipos deben auditar sus configuraciones de nube en busca de credenciales federadas no autorizadas o cambios en las políticas de confianza. Además, el uso de hooks postinstall de npm significa que la amenaza se extiende más allá del entorno de CI hasta las estaciones de trabajo de los desarrolladores. Cualquier miembro del equipo que haya extraído el código malicioso podría haber instalado inadvertidamente malware, requiriendo un esfuerzo de respuesta a incidentes más amplio.

Qué puede hacer

• Auditar repositorios: Busque ramas llamadas "wfx-docs", "chore/[a-z0-9]{8}" o solicitudes de pull con el título "docs: dependency audit notes".
• Rotar credenciales: Rote inmediatamente todos los secretos, variables y tokens en los repositorios afectados. Revogue los permisos de aplicaciones OAuth y las claves SSH para las cuentas comprometidas.
• Revisar logs de la nube: Busque actividad inusual en AWS CloudTrail, Azure Entra ID y logs de GCP, específicamente para "AssumeRoleWithWebIdentity" o credenciales federadas con prefijo "wfx-ci-".
• Inspeccionar máquinas locales: Si ejecutó "npm install" sobre un commit potencialmente afectado, trate su máquina como comprometida y rote las claves locales.
• Bloquear paquetes maliciosos: Fije digitalelvis/neuronai-studio a v3.14.2 o anterior y elimine las versiones afectadas de github.com/onuragtas/docker-env y github.com/vkuznet/gocurl.
• Habilitar 2FA: Asegúrese de que la autenticación de dos factores esté habilitada para todas las cuentas de GitHub para prevenir ataques de credential stuffing.