Un atacante utilizó credenciales robadas de más de 4,800 cuentas de GitHub para implantar un software malicioso en miles de repositorios. El objetivo era robar secretos, tokens y credenciales de nube mediante los flujos de trabajo de CI, afectando a al menos 1,806 proyectos. Se recomienda tratar como comprometidos todos los secretos de los repositorios donde se detecten pull requests titulados docs: dependency audit notes.





 Desde el martes, un atacante utilizó credenciales robadas de 4,837 cuentas de GitHub para plantar un robador de secretos en repositorios donde esas cuentas tenían permisos de escritura, según Aikido Security, una empresa de software de seguridad.

El robador está diseñado para extraer los secretos y credenciales de la nube a los que pueden acceder los flujos de trabajo de CI de un repositorio. Se ejecutó en al menos 1,806 repositorios, donde es probable que el atacante haya recolectado dichas credenciales, afirma la compañía.

Cada ataque comenzó con una solicitud de extracción (pull request) titulada "docs: dependency audit notes", abierta desde una rama llamada "wfx-docs" para probar si la cuenta podía escribir en el repositorio. Estas solicitudes de prueba se enviaron a 61,764 repositorios, y el robador se implementó en algunos de ellos.

Tras insertar el robador, el atacante revirtió el cambio en menos de un minuto y generalmente eliminó la ejecución del flujo de trabajo y sus registros. En aquellos casos donde el robador se ejecutó, cada secreto y rol de nube disponible en los flujos de trabajo del repositorio debe considerarse comprometido.

Se detectó que hoy temprano se abrieron más solicitudes de extracción con el mismo título, después de que la búsqueda de GitHub de la empresa terminara el miércoles. Tres de ellas, abiertas entre las 05:04 y 05:38 UTC, provenían de ramas "wfx-docs". No está claro si el robador fue implementado.

Cualquier cuenta que haya abierto una de las solicitudes de prueba del atacante está comprometida, incluso si el robador nunca se ejecutó, señaló Aikido en su análisis técnico [enlace]. El análisis no explica cómo el atacante obtuvo las credenciales ni ofrece consejos para los propietarios de las cuentas robadas.

En la mayoría de los demás repositorios que recibieron una prueba, no se insertó nada posteriormente, o el robador no se ejecutó debido a la configuración del repositorio o a los permisos de la cuenta. Las cifras cubren únicamente los repositorios públicos que la empresa pudo visualizar.

Las pruebas también alcanzaron repositorios que las cuentas comprometidas no poseían. De las solicitudes de prueba, 10,431 se enviaron a través de acceso de colaborador u organización, y el 92% de ellas seguían abiertas cuando la empresa realizó la comprobación.

Signos de que un repositorio fue afectado

La empresa enumera estas señales que debes revisar, desde el martes en adelante, en cualquier repositorio donde puedas escribir:

• * Rama: wfx-docs
• * Rama: chore/[a-z0-9]{8}, de corta duración
• * Rama: ci-check-[0-9]{4}
• * Título de pull request: docs: dependency audit notes
• * Mensaje de commit: ci: refresh build cache, que añade unas 1,500 líneas a un flujo de trabajo existente
• * Mensaje de commit: chore: add ci helper, que añade un script .ci-xxxxxx.sh y un hook de postinstall en package.json que lo ejecuta en cualquier npm install
• * Mensaje de commit: chore: add dependency audit workflow, que añade .github/workflows/build-audit-xxxxxx.yml en una rama chore/
• * Mensaje de commit: ci: restore
• * Mensaje de commit: ci: cleanup
• * SHA-256 (script robador): 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf
• * IP: 194.150.166[.]244:8080/exfil
• * IP: 18.143.168[.]96:8080/exfil

Un repositorio puede no mostrar artefactos "wfx-loot", entradas de "wfx-cache" o resúmenes de paso "WFX-BEGIN" y aun así haber perdido datos. En esta campaña, el robador estaba configurado para enviar datos solo mediante HTTP POST a las dos direcciones anteriores.

La falta de un número de ejecución en el commit del atacante es la señal más fiable de que el robador se ejecutó.

El robador está diseñado para recolectar credenciales de todas las fuentes del ejecutor (runner), según la empresa. Estas incluyen secretos y variables de GitHub Actions, el GITHUB_TOKEN del flujo de trabajo, tokens OIDC y de tiempo de ejecución de Actions, claves para servicios de IA y secretos en la memoria de los propios procesos del ejecutor. Lee archivos de credenciales de AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH y otras herramientas desde sus ubicaciones habituales.

También copia el repositorio, sus últimos 100 commits y los artefactos recientes del flujo de trabajo. En ejecutores auto-alojados, toma credenciales de la nube de los metadatos de la instancia, así como el estado del contenedor Docker y las unidades de systemd.

El robador también tiene configuraciones para repositorios privados, y la empresa dice que esto sugiere que podría estar ejecutándose en ellos.

El robador está diseñado para usar esas credenciales para acceder más profundamente en las cuentas de la nube. Intercambia tokens OIDC de GitHub por sesiones de AWS, GCP y Azure, y en AWS puede crear claves de acceso de larga duración para usuarios de IAM.

Algunos de sus pasos están creados para sobrevivir a la rotación de credenciales. Puede reescribir la política de confianza de un rol de AWS para abrir el rol a cualquier cuenta de AWS.

También puede añadir credenciales de identidad federada con el prefijo "wfx-ci-" a aplicaciones de Azure AD. Los flujos de trabajo en el repositorio comprometido pueden entonces iniciar sesión en Azure sin un secreto almacenado, incluso después de que todos los tokens hayan sido rotados.

El robador alcanzó al menos un paquete de Packagist y un módulo de Go a través de activadores de publicación automatizados. Al menos 50 de los usuarios comprometidos parecen publicar paquetes para npm, Go, Packagist, PyPI o crates.

El atacante parece buscar secretos de CI en lugar de intentar propagarse a través de paquetes, afirma la empresa.

La versión 3.14.3 del paquete de Packagist digitalelvis/neuronai-studio es maliciosa, y cualquier máquina que la haya instalado o abierto debe considerarse comprometida. Su listado de paquetes [enlace] muestra que la versión fue publicada el miércoles. Hoy temprano, la versión todavía aparecía listada, bajo un aviso de que versiones del paquete habían sido marcadas como malware.

Dos versiones del módulo de Go github.com/onuragtas/docker-env, v1.0.278 y v1.0.280, llevan el robador solo en un archivo de flujo de trabajo de GitHub Actions. El código de Go y los binarios de lanzamiento no han cambiado, y las compilaciones de Go nunca ejecutan archivos de flujo de trabajo, por lo que es posible que los usuarios del módulo no se hayan visto afectados. No obstante, la empresa recomienda eliminar esas versiones.

Las cuentas utilizadas esta semana coinciden con las afectadas en la ola de GhostAction de octubre, en la que cuentas de GitHub robadas insertaron flujos de trabajo para robar secretos en repositorios.

Las cuentas afectadas en octubre tenían unas 1,000 veces más probabilidades que otras cuentas activas de ser utilizadas esta semana. En más de 100 repositorios, el nuevo robador fue añadido a los archivos de flujo de trabajo de octubre, manteniendo en su lugar el paso más antiguo que envía los datos.

Aikido señaló: "no atribuimos noviembre al mismo actor en esta etapa", porque la infraestructura, las herramientas y los métodos difieren, y las credenciales robadas a menudo terminan en manos de varios atacantes.

Fuente:
THN