Una brecha en un flujo de trabajo de SpotBugs desencadenó una compleja campaña de ataque en la cadena de suministro de GitHub que acabó comprometiendo secretos en más de 200 repositorios.
Un reciente análisis de los investigadores de Unit 42 de Palo Alto Networks ha arrojado luz sobre el origen de una serie de ataques en cascada que afectaron a múltiples proyectos en GitHub, incluyendo uno dirigido a la plataforma de criptomonedas Coinbase. El punto de entrada inicial fue un token personal (PAT) filtrado accidentalmente en un flujo de integración continua (CI) de SpotBugs, una herramienta muy popular de análisis estático de código.
Una cadena de confianza rota desde noviembre de 2024
Según la investigación, el ataque comenzó en noviembre de 2024 cuando un mantenedor de SpotBugs incluyó inadvertidamente su token personal en un flujo de trabajo. El 6 de diciembre, un atacante aprovechó un flujo vulnerable (pull_request_target) para robar ese token mediante una pull request maliciosa enviada desde una cuenta desechable llamada randolzflow.
Tres meses después, el atacante utilizó el token robado para invitar a un nuevo usuario falso, jurkaofavak, al proyecto. Este usuario ejecutó un nuevo ataque en SpotBugs, que permitió robar un segundo token, esta vez perteneciente a un mantenedor de Reviewdog con permisos sobre el repositorio reviewdog/action-setup.
Con este acceso, el atacante sustituyó el tag v1 por un commit malicioso, abriendo una puerta trasera que afectó a los proyectos que usaban esa versión, incluido tj-actions/eslint-changed-files. Este componente, a su vez, era consumido por repositorios como coinbase/agentkit, lo que extendió la amenaza a uno de los mayores exchanges de criptomonedas del mundo.
218 repositorios expuestos, pero Coinbase logró evitar lo peor
Aunque inicialmente se pensaba que hasta 23.000 repositorios podrían haberse visto comprometidos, los análisis posteriores confirmaron que el impacto directo se limitó a 218 repositorios. En el caso concreto de Coinbase, la versión infectada fue ejecutada el 14 de marzo, pero no se expusieron secretos críticos gracias a la rápida intervención del equipo de seguridad de la compañía, que eliminó el flujo comprometido.
Un ataque planificado con meses de antelación
Este incidente no solo revela un ataque bien organizado y ejecutado a lo largo de varios meses, sino que también pone en evidencia graves debilidades estructurales en la cadena de confianza de los ecosistemas de código abierto y en GitHub Actions:
- Mutable tags (etiquetas que pueden apuntar a nuevos commits sin historial claro).
- Auditorías deficientes de logs.
- Dependencia de flujos inseguros como
pull_request_target.
Recomendaciones clave para desarrolladores y mantenedores
Las organizaciones que usaron las acciones comprometidas deben actuar de inmediato:
- Rotar todos los secretos expuestos en los flujos de trabajo entre el 10 y 14 de marzo.
- Auditar los logs de GitHub Actions buscando salidas inusuales, como blobs en base64.
- Evitar
pull_request_targetsalvo que sea estrictamente necesario. - Anclar dependencias a hashes de commit, en lugar de confiar en tags como
v1.
Este ataque vuelve a recordar que, en el mundo del software libre, la seguridad no termina en el código fuente: también hay que proteger la infraestructura de CI/CD y adoptar buenas prácticas de gestión de secretos y versiones.
fuente: BC
