Esto lo convierte en un buen objetivo para implementar algo así como un troyano que se conecta con los atacantes y luego recopila toda la información confidencial posible expuesta por futuras ejecuciones de flujo de trabajo. Pero ¿qué utilizar como troyano que no sería detectado por los productos antivirus o cuyas comunicaciones no serían bloqueadas? El propio agente ejecutor de GitHub Actions, o más bien otra instancia del mismo que no está vinculada a la organización PyTorch sino a una organización GitHub controlada por los atacantes.
“Nuestra técnica ‘Runner on Runner’ (RoR) utiliza los mismos servidores para C2 que el ejecutor existente, y el único binario que eliminamos es el binario oficial del agente de ejecutor de GitHub, que ya se está ejecutando en el sistema. Nos vemos, EDR y protecciones de firewall”, dijo Stawinski.
Extracción de tokens de acceso confidenciales
Hasta este paso, los atacantes lograron ejecutar un programa troyano muy sigiloso dentro de una máquina que forma parte de la infraestructura de desarrollo de la organización y que se utiliza para ejecutar trabajos confidenciales como parte de su proceso de CI/CD. El siguiente paso es la post-explotación: intentar exfiltrar datos confidenciales y trasladarlos a otras partes de la infraestructura.
Los flujos de trabajo suelen incluir tokens de acceso al propio GitHub o a otros servicios de terceros. Estos tokens son necesarios para que los trabajos definidos en el flujo de trabajo se ejecuten correctamente. Por ejemplo, el agente de compilación necesita privilegios de lectura para verificar el repositorio primero y también puede necesitar acceso de escritura para publicar el binario resultante como una nueva versión o para modificar las versiones existentes.
Estos tokens se almacenan en el sistema de archivos del ejecutor en varias ubicaciones, como el archivo de configuración.git o en variables de entorno, y obviamente pueden ser leídos por el «troyano» sigiloso que se ejecuta con privilegios de root. Algunos, como GITHUB_TOKEN, son efímeros y sólo válidos durante la ejecución del flujo de trabajo, pero los investigadores encontraron formas de extender su vida. Incluso si no hubieran encontrado estos métodos, los nuevos flujos de trabajo con tokens recién generados se ejecutan todo el tiempo en un repositorio ocupado como PyTorch, por lo que hay muchos nuevos para recopilar.
«El repositorio de PyTorch utilizó secretos de GitHub para permitir a los corredores acceder a sistemas confidenciales durante el proceso de lanzamiento automatizado», dijo Stawinski. «El repositorio utilizaba muchos secretos, incluidos varios conjuntos de claves de AWS y tokens de acceso personal (PAT) de GitHub».
Las PAT suelen tener privilegios excesivos y son un objetivo atractivo para los atacantes, pero en este caso se utilizaron como parte de otros flujos de trabajo que no se ejecutaban en el ejecutor autohospedado comprometido. Sin embargo, los investigadores encontraron formas de utilizar los tokens efímeros de GitHub que pudieron recopilar para colocar código malicioso en flujos de trabajo que se ejecutaban en otros corredores y contenían esas PAT.
«Resulta que no se puede utilizar GITHUB_TOKEN para modificar archivos de flujo de trabajo», dijo Stawinski. “Sin embargo, descubrimos varias… ‘soluciones alternativas’ creativas… que le permitirán agregar código malicioso a un flujo de trabajo utilizando un GITHUB_TOKEN. En este escenario, Weekly.yml usó otro flujo de trabajo, que usó un script fuera del directorio .github/workflows. Podríamos agregar nuestro código a este script en nuestra rama. Luego, podríamos activar ese flujo de trabajo en nuestra rama, que ejecutaría nuestro código malicioso. Si esto le parece confuso, no se preocupe; también confunde a la mayoría de los programas de recompensas por errores”.
En otras palabras, incluso si un atacante no puede modificar un flujo de trabajo directamente, es posible que pueda modificar un script externo llamado por ese flujo de trabajo y obtener su código malicioso de esa manera. Los repositorios y los flujos de trabajo de CI/CD pueden volverse bastante complejos con muchas interdependencias, por lo que estos pequeños descuidos no son infrecuentes.
Incluso sin las PAT, el GITHUB_TOKEN solo con privilegios de escritura habría sido suficiente para envenenar las versiones de PyTorch en GitHub y las claves de AWS extraídas por separado podrían haberse utilizado para realizar puertas traseras a las versiones de PyTorch alojadas en la cuenta de AWS de la organización. «Había otros conjuntos de claves de AWS, PAT de GitHub y varias credenciales que podríamos haber robado, pero creíamos que teníamos una demostración clara del impacto en este punto», dijeron los investigadores. «Dada la naturaleza crítica de la vulnerabilidad, queríamos presentar el informe lo antes posible antes de que uno de los 3.500 contribuyentes de PyTorch decidiera hacer un trato con un adversario extranjero».
Mitigar el riesgo de los flujos de trabajo de CI/CD
Hay muchas lecciones que aprender de este ataque para las organizaciones de desarrollo de software: desde los riesgos asociados con la ejecución de ejecutores de GitHub Actions autohospedados en configuraciones predeterminadas hasta los riesgos de tener flujos de trabajo que ejecutan scripts desde fuera del directorio de flujos de trabajo y los riesgos asociados con tokens de acceso con privilegios excesivos. y aplicaciones legítimas reutilizadas como troyanos. Otros investigadores hicieron esto antes con el agente AWS System Manager de Amazon. y con La solución de administración de dispositivos y SSO de Google para Windows.
«Asegurar y proteger a los corredores es responsabilidad de los usuarios finales, no de GitHub, por lo que GitHub recomienda no utilizar corredores autohospedados en repositorios públicos», dijo Stawinski. «Aparentemente, no todo el mundo escucha GitHub, incluido GitHub».
Sin embargo, si son necesarios corredores autohospedados, las organizaciones deberían al menos considerar cambiar la configuración predeterminada de «Requerir aprobación para quienes contribuyen por primera vez» a «Requerir aprobación para todos los colaboradores externos». También es una buena idea hacer que los ejecutores autohospedados sean efímeros y ejecutar flujos de trabajo desde relaciones públicas de bifurcación solo en ejecutores alojados en GitHub.
Esta no es la primera vez que uso inseguro de las funciones de GitHub Actions ha generado riesgos de seguridad en la cadena de suministro de software. Otros servicios y plataformas de CI/CD También han tenido sus propias vulnerabilidades y configuraciones predeterminadas inseguras.. «Los problemas que rodean estas rutas de ataque no son exclusivos de PyTorch», dijeron los investigadores. “No son exclusivos de los repositorios de ML ni siquiera de GitHub. Hemos demostrado repetidamente las debilidades de la cadena de suministro al explotar las vulnerabilidades de CI/CD en las organizaciones tecnológicas más avanzadas del mundo en varias plataformas de CI/CD, y esas son solo un pequeño subconjunto de la mayor superficie de ataque”.