28°C lluvia ligera
La campaña Gheist explotó tokens de GitHub robados para copiar los secretos de repositorios privados en más de 850 cuentas, con más de 13,500 ramas plantadas desde el 15 de septiembre. Wiz Research publicó su informe el domingo 25 de octubre y documentó ejecuciones completas en repositorios privados y en entornos empresariales, donde el control de seguridad de GitHub no alcanza.
Para quien programa en República Dominicana o guarda en GitHub el código de un negocio, el aviso toca de cerca. No hizo falta una falla nueva en la plataforma: bastó un token robado para entrar como si fuera el dueño y salir con claves de nube y de bases de datos.
Una rama falsa bastaba para vaciar los secretos
La herramienta crea en cada repositorio una rama llamada ci-sync- seguida de seis caracteres al azar. En esa rama sube un único archivo, .github/workflows/sync-check.yml, con el mensaje «ci: sync config» y firmado a nombre del dueño del token. El archivo es un flujo de GitHub Actions.
Al correr, el flujo imprime los secretos del repositorio dentro de su propio registro, codificados en base32. GitHub oculta esos valores solo cuando aparecen tal cual fueron guardados; al salir codificados, no los reconoce y quedan a la vista. La herramienta descarga ese registro por la propia interfaz de GitHub y borra la ejecución segundos después, sin ningún dominio externo que un cortafuegos pueda bloquear.
El alcance crecía cuando el repositorio tenía entornos de despliegue. El flujo armaba una lista con esos entornos y sacaba también sus secretos, que suelen ser las credenciales de producción. En las empresas observadas, la herramienta rotó tokens de varios usuarios en minutos, clonó repositorios privados y, horas después, credenciales de nube se usaron para revisar AWS Secrets Manager, el servicio de Amazon que guarda secretos.
El freno de GitHub protege los repositorios públicos
Desde el 28 de julio, GitHub retiene las ejecuciones de flujos con señales sospechosas en los repositorios públicos hasta que un colaborador las aprueba. Wiz revisó las ejecuciones públicas de la campaña y cada una quedó detenida en ese estado de espera: el control funcionó y el código malicioso nunca corrió en ese lado.
Esa retención no se aplica a los repositorios privados ni a GitHub Enterprise Server. Ahí los registros de auditoría muestran ejecuciones sobre ramas ci-sync- que terminaban y luego eran borradas por un agente que se identifica como gheist. Al 24 de octubre la operación seguía activa y cerca de dos tercios de las cuentas implicadas ya no aparecían en GitHub tras el aviso de Wiz.
Los tokens de GitHub usados en la campaña Gheist llegaban de registros de programas que roban información de computadoras infectadas y de claves expuestas en incidentes anteriores, entre ellos el caso Trivy de marzo. El 19 de octubre apareció una variante más agresiva: un segundo flujo buscaba en las máquinas propias 31 formatos de claves, entre ellas las de Anthropic, Hugging Face, Groq y NVIDIA, además de archivos .env y llaves privadas.
Las señales para revisar la cuenta hoy
La revisión empieza por las ramas: cualquier rama ci-sync- que nadie del equipo reconozca, con un solo cambio y el mensaje «ci: sync config», merece trato de incidente. También pesan las ejecuciones borradas a menos de un minuto de terminar y, en las máquinas propias, los archivos .gdmp_pat, .gdmp_patg y .gdmp_sweep.
Si aparece una de esas señales, Wiz pide rotar todos los secretos al alcance del repositorio, revocar el token que empujó la rama y revisar la computadora de su dueño. Borrar la rama no deshace la exposición, y las ejecuciones retenidas de sync-check no se aprueban. El endurecimiento queda para después: revisores obligatorios en los entornos con secretos de producción, tokens de corta duración y alcance fino, y máquinas propias desechables.
Fuente: The Hacker News
Foto: The Hacker News
Discover more from Últimas noticias al instante de República Dominicana – EnMinutos.net
Subscribe to get the latest posts sent to your email.
