Gheist usa tokens de GitHub robados para vaciar en silencio los secretos de repositorios privados. Un token vigente basta: la herramienta entra, planta un flujo de trabajo en cada proyecto que ese token alcanza y se lleva las claves guardadas para GitHub Actions. Wiz recuperó más de 13.500 ramas y contó más de 850 cuentas comprometidas, desde proyectos personales hasta repositorios privados de empresas.
El seguimiento empezó el 15 de septiembre. El nombre Gheist sale del agente de usuario «gheist» que la herramienta deja en sus peticiones a la interfaz de programación de aplicaciones (API) de GitHub. Al 24 de octubre la campaña seguía activa y cambiando, y cerca de dos tercios de las cuentas implicadas ya no aparecían en la plataforma. Wiz informó la actividad a GitHub y lee esa desaparición como efecto de la respuesta del servicio.
Gheist: una rama falsa y el registro hace el resto
El mecanismo es corto y feo. Para cada repositorio, la herramienta crea una rama con el nombre «ci-sync-» seguido de seis caracteres al azar y sube un único archivo, .github/workflows/sync-check.yml, con el mensaje de confirmación «ci: sync config». La confirmación va sin firmar y figura a nombre del dueño del token. Ese envío dispara el flujo de forma automática.
Una vez en marcha, el flujo imprime el entorno del trabajo y cada secreto que puede leer, convertido a base32, una codificación de texto. GitHub oculta los secretos en los registros, pero solo reconoce el valor exacto tal como está guardado; al salir codificado, el valor ya no coincide y se imprime completo. La documentación de la plataforma recuerda que cualquier persona con acceso de escritura a un repositorio puede leer todos sus secretos configurados.
El cierre del ciclo dura segundos. La herramienta descarga el registro por la API de GitHub y borra la ejecución enseguida. Los secretos salen por la misma puerta del servicio, sin servidor del atacante ni conexión externa que bloquear. Una variante recorrió aparte los entornos de despliegue de cada repositorio, donde suelen vivir las credenciales de producción.
Los ejecutores propios entraron en la mira el 19 de octubre
Una versión fechada hacia el 19 de octubre sumó un segundo trabajo pensado para los ejecutores propios, las máquinas que cada organización opera para procesar sus flujos de Actions. Ese trabajo busca 31 tipos de credenciales: llaves privadas, entornos de procesos, credenciales del rol en Amazon Web Services (AWS), archivos del ejecutor y el token de Kubernetes. Wiz lo describe como un código con fallos y no registra ninguna ejecución exitosa en ese frente.
El escudo de GitHub cubre lo público, no lo privado
Desde el 28 de julio, GitHub retiene los flujos que marca como posiblemente maliciosos hasta que un colaborador con acceso de escritura los apruebe. Wiz revisó las ejecuciones públicas de Gheist y todas seguían esperando aprobación: la carga nunca corrió en abierto. El problema está en el alcance, limitado a los repositorios públicos de github.com. Los privados y GitHub Enterprise Server quedan fuera, y allí los registros de auditoría muestran ejecuciones completadas en ramas sembradas y borradas poco después.
En varias empresas, la herramienta rotó en minutos por tokens de distintos usuarios y cuentas de automatización, clonó repositorios privados antes de sembrar el flujo y, horas más tarde, credenciales de nube de la misma organización se usaron para enumerar AWS Secrets Manager, el gestor de secretos de Amazon. Wiz no precisa de dónde salieron esas credenciales. El origen de los tokens de GitHub robados sí tiene dos vías rastreadas: registros de programas ladrones de información en equipos de desarrolladores y credenciales expuestas en ataques previos a la cadena de suministro, entre ellos el compromiso de marzo del escáner Trivy.
El botín compartido complica la foto. El 6 de octubre, 391 cuentas —muchas usadas también por Gheist— renombraron cerca de 1.461 repositorios para disfrazarlos de programas piratas. La campaña Megalodon, que en mayo empujó flujos ladrones de secretos a miles de repositorios, había tocado 57 de las mismas cuentas. Un mismo token robado puede servir a varios grupos a la vez.
Qué revisar antes de que aparezca una rama ci-sync
La señal de búsqueda es concreta: ramas «ci-sync-» cuyo único cambio sea el archivo sync-check.yml con el mensaje «ci: sync config», ejecuciones borradas a menos de un minuto de terminar y actividad del agente «gheist» en los registros de auditoría. Quienes conectan sus flujos con la nube mediante OpenID Connect (OIDC), el estándar de sesión con tokens de vida corta, pueden buscar asunciones de rol cuyo asunto incluya una rama ci-sync, incluso sin recoger registros de GitHub.
Si una rama así corrió, borrarla no deshace nada. Wiz pide rotar cada secreto que el repositorio podía usar —de repositorio, de organización y de entorno—, revocar los tokens que empujaron las confirmaciones y revisar los equipos de sus dueños en busca de ladrones de información. Si el flujo tocó un ejecutor propio, esa máquina y su rol de nube se tratan como comprometidos. La prevención pasa por exigir revisores en entornos con secretos de producción, limitar la confianza OIDC a ramas protegidas, usar tokens de grano fino de vida corta y correr los ejecutores propios como máquinas desechables.
Un dato sigue sin aparecer en el análisis de Wiz: cuántas organizaciones perdieron secretos. La cifra de ramas y cuentas es pública; la de empresas con claves ya fuera, no.
Fuente: The Hacker News
Foto: The Hacker News
Descubre más desde Tecnología Geek
Suscríbete y recibe las últimas entradas en tu correo electrónico.
