Los proyectos de software, en riesgo por las descargas inseguras en GitHub Actions

La forma en que la plataforma GitHub Actions almacena los artefactos de compilación podría permitir a los atacantes inyectar código malicioso en proyectos de software con flujos de trabajo de CI/CD (integración continua y entrega continua) que no filtran lo suficiente al descargar artefactos. Los investigadores de ciberseguridad han identificado varios scripts de descarga de artefactos populares utilizados por miles de repositorios que son vulnerables a este problema.

“Descubrimos que cuando se transfieren artefactos entre diferentes flujos de trabajo, existe un gran riesgo de envenenamiento, una técnica en la que los atacantes reemplazan el contenido de un artefacto legítimo por uno malicioso modificado y, por lo tanto, inician un ataque a la cadena de suministro”, según un estudio de Legit Security en un análisis del problema.

Para atacar la canalización de CI/CD de un proyecto vulnerable que descarga y usa artefactos generados por otros flujos de trabajo, los atacantes solo necesitan bifurcar los repositorios que contienen esos flujos de trabajo, modificarlos en sus copias locales para que produzcan artefactos no autorizados y luego realizar solicitudes de extracción de vuelta al original.

Un fallo lógico en las API de almacenamiento de artefactos

GitHub Actions es una plataforma de CI/CD para automatizar la creación y prueba de código de software. El servicio es gratuito para repositorios públicos e incluye minutos gratuitos de tiempo de ejecución del trabajador y espacio de almacenamiento para repositorios privados. Es ampliamente adoptado por proyectos que usan GitHub para alojar y administrar sus repositorios de código fuente. 

Los flujos de trabajo de GitHub Actions son procesos automatizados definidos en archivos .yml que utilizan la sintaxis YAML que se ejecutan cuando ocurren ciertos desencadenantes o eventos, como cuando se confirma código nuevo en el repositorio. Los artefactos de compilación son archivos binarios, registros y otros archivos compilados que resultan de la ejecución de un flujo de trabajo y sus trabajos individuales. Estos artefactos se guardan dentro de cubos de almacenamiento y a cada ejecución de flujo de trabajo se le asigna un cubo particular donde puede cargar archivos y luego descargarlos.

La 'acción' (secuencia de comandos) de referencia para descargar artefactos proporcionada por GitHub no admite descargas de artefactos entre flujos de trabajo, pero la reutilización de artefactos generados por diferentes flujos de trabajo como entrada para los pasos de compilación de seguimiento son casos de uso comunes para proyectos de software. Es por eso que los desarrolladores crearon sus propios scripts personalizados que se basan en la API de acciones de GitHub para descargar artefactos mediante un filtrado más complejo, como artefactos creados por un archivo de flujo de trabajo específico, un usuario específico, una rama específica, etc.

El problema que encontró Legit Security es que la API no diferencia entre los artefactos cargados por repositorios bifurcados y los repositorios base, por lo que si un script de descarga filtra los artefactos generados por un archivo de flujo de trabajo particular de un repositorio en particular, la API servirá la última versión de el artefacto generado por ese archivo, pero podría ser una versión maliciosa generada automáticamente a través de una acción de solicitud de extracción desde una versión bifurcada del repositorio.

“En pocas palabras: en un flujo de trabajo vulnerable, cualquier usuario de GitHub puede crear una bifurcación que construya un artefacto”, dijeron los investigadores. “Luego inyecte este artefacto en el proceso de creación del repositorio original y modifique su salida. Esta es otra forma de ataque a la cadena de suministro de software, donde un atacante modifica la salida de la compilación.

Los investigadores encontraron cuatro acciones personalizadas desarrolladas por la comunidad para descargar artefactos que eran vulnerables. Uno de ellos figuraba como dependencia para más de 12.000 repositorios.

Uno de los repositorios que utilizó un script personalizado de este tipo en uno de sus flujos de trabajo fue el repositorio oficial del lenguaje de programación Rust. El flujo de trabajo vulnerable, llamado ci.yml, fue responsable de construir y probar el código del repositorio y usó la acción personalizada para descargar un artefacto llamado libgccjit.so, un archivo de biblioteca de Linux, que fue generado por un flujo de trabajo en un repositorio de terceros.

Todo lo que los atacantes tenían que hacer era bifurcar el repositorio de terceros, modificar el flujo de trabajo de ese repositorio para generar una versión maliciosa de la biblioteca y emitir una solicitud de extracción al repositorio original para generar el artefacto. Si el flujo de trabajo de Rust hubiera extraído la versión envenenada de la biblioteca, habría brindado a los atacantes la capacidad de ejecutar código malicioso dentro del repositorio de Rust con los privilegios del flujo de trabajo.

“Después de la explotación, el atacante podría modificar las ramas del repositorio, las solicitudes de extracción, los problemas, los lanzamientos y todas las entidades que están disponibles para los permisos del token de flujo de trabajo”, dijeron los investigadores.

Los usuarios deben aplicar un filtrado más estricto para las descargas de artefactos

GitHub respondió al informe de Legit agregando más capacidades de filtrado a la API que los desarrolladores pueden usar para identificar mejor los artefactos creados por una instancia de ejecución específica del flujo de trabajo (ID de ejecución de flujo de trabajo). Sin embargo, este cambio no se puede forzar en las implementaciones existentes sin interrumpir los flujos de trabajo, por lo que depende de los usuarios actualizar sus flujos de trabajo con un filtrado más estricto para estar protegidos.

Otra mitigación es filtrar los artefactos descargados por el valor hash de las confirmaciones que los generaron o excluyendo los artefactos creados por solicitud de extracción por completo mediante la opción exclude_pull_requests. Legit Security también se puso en contacto con los autores de los scripts de descarga de artefactos personalizados vulnerables que encontraron.

“En la seguridad de la cadena de suministro, la atención se ha centrado en evitar que las personas contribuyan con código malicioso, por lo que cada vez que realiza un cambio en un repositorio, crea una solicitud de extracción o realiza una solicitud de cambio, GitHub tiene muchos controles de verificación integrados, ” Liav Caspi, CTO de Legit Security le dice a CSO. “Alguien tiene que aprobar tu código, alguien tiene que fusionarlo, así que hay una persona involucrada. Lo que hemos estado tratando de encontrar son técnicas que exploten un problema lógico en el que cualquier persona pueda influir sin revisión y creo que esta es una de ellas. Si alguien lo hubiera sabido, podría haber inyectado el artefacto sin ninguna aprobación”.

Por lo general, las canalizaciones de CI tienen flujos de trabajo que se ejecutan automáticamente en solicitudes de extracción para probar el código antes de que se revise manualmente y si la solicitud de extracción contiene algún artefacto que debe construirse, el flujo de trabajo lo construirá, dijo Caspi. Un atacante sofisticado podría crear la solicitud de extracción para construir el artefacto y luego eliminar la solicitud cerrando el envío y lo más probable es que con todo el ruido de actividad que existe en los repositorios de código fuente hoy, pasaría desapercibido, dijo.