Configuraciones erróneas de integración continua y entrega continua (CI/CD) descubiertas en el código abierto TensorFlow El marco de aprendizaje automático podría haberse aprovechado para orquestar ataques a la cadena de suministro.
Un atacante podría abusar de las configuraciones erróneas para «llevar a cabo un compromiso de la cadena de suministro de las versiones de TensorFlow en GitHub y PyPi al comprometer los agentes de compilación de TensorFlow a través de una solicitud de extracción maliciosa», dijeron los investigadores de Praetorian Adnan Khan y John Stawinski. dicho en un informe publicado esta semana.
La explotación exitosa de estos problemas podría permitir a un atacante externo cargar versiones maliciosas en el repositorio de GitHub, obtener la ejecución remota de código en el ejecutor de GitHub autohospedado e incluso recuperar un token de acceso personal (PAT) de GitHub para el usuario tensorflow-jenkins.
TensorFlow utiliza GitHub Actions para automatizar el proceso de creación, prueba e implementación de software. Los ejecutores, que se refieren a máquinas que ejecutan trabajos en un flujo de trabajo de GitHub Actions, pueden ser autohospedados o alojados en GitHub.
«Recomendamos que utilice únicamente ejecutores autohospedados con repositorios privados», GitHub notas en su documentación. «Esto se debe a que las bifurcaciones de su repositorio público pueden potencialmente ejecutar código peligroso en su máquina ejecutora autohospedada al crear una solicitud de extracción que ejecuta el código en un flujo de trabajo».
Dicho de otra manera, esto permite a cualquier colaborador ejecutar código arbitrario en el ejecutor autohospedado enviando una solicitud de extracción maliciosa.
Sin embargo, esto no plantea ningún problema de seguridad con los ejecutores alojados en GitHub, ya que cada ejecutor es efímero y es una máquina virtual limpia y aislada que se destruye al final de la ejecución del trabajo.
Praetorian dijo que pudo identificar flujos de trabajo de TensorFlow que se ejecutaron en ejecutores autohospedados y posteriormente encontró solicitudes de extracción de bifurcación de colaboradores anteriores que activaron automáticamente los flujos de trabajo de CI/CD apropiados sin requerir aprobación.
Por lo tanto, un adversario que busque trojanizar un repositorio de destino podría corregir un error tipográfico o realizar un pequeño pero legítimo cambio de código, crear una solicitud de extracción para ello y luego esperar hasta que la solicitud de extracción se fusione para convertirse en colaborador. Esto les permitiría ejecutar código en el corredor sin generar ninguna señal de alerta mediante la creación de una solicitud de extracción no autorizada.
Un examen más detenido de los registros de flujo de trabajo reveló que el ejecutor autohospedado no sólo era no efímero (abriendo así la puerta a la persistencia), sino que también GITHUB_TOKEN Los permisos asociados con el flujo de trabajo incluían amplios permisos de escritura.
«Porque el GITHUB_TOKEN tenía la Contenido:permiso de escriturapodría cargar lanzamientos en https://github[.]com/tensorflow/tensorflow/releases/», dijeron los investigadores. «Un atacante que comprometiera uno de estos `GITHUB_TOKEN podría agregar sus propios archivos a los Activos de lanzamiento».
Además de eso, los permisos de contenido:escritura podrían usarse como arma para enviar código directamente al repositorio de TensorFlow inyectando de forma encubierta el código malicioso en un rama característica y fusionarlo con la rama principal.
Eso no es todo. Un actor de amenazas podría robar el AWS_PYPI_ACCOUNT_TOKEN utilizado en el flujo de trabajo de lanzamiento para autenticarse en el registro del Índice de paquetes de Python (PyPI) y cargar un archivo Python .whl malicioso, envenenando efectivamente el paquete.
«Un atacante también podría usar los permisos de GITHUB_TOKEN para comprometer el secreto del repositorio JENKINS_TOKEN, aunque este secreto no se usó dentro de los flujos de trabajo que se ejecutaron en los corredores autohospedados», dijeron los investigadores.
Tras la divulgación responsable el 1 de agosto de 2023, los mantenedores del proyecto abordaron las deficiencias a partir del 20 de diciembre de 2023, exigiendo la aprobación de los flujos de trabajo enviados desde todas las solicitudes de extracción de bifurcaciones y cambiando los permisos GITHUB_TOKEN a solo lectura para los flujos de trabajo que se ejecutaron en corredores autohospedados.
«Los ataques CI/CD similares están aumentando a medida que más organizaciones automatizan sus procesos CI/CD», dijeron los investigadores.
«Las empresas de IA/ML son particularmente vulnerables ya que muchos de sus flujos de trabajo requieren una potencia informática significativa que no está disponible en los ejecutores alojados en GitHub, de ahí la prevalencia de los ejecutores autohospedados».
La divulgación se produce cuando ambos investigadores revelaron que varios repositorios públicos de GitHubincluidos aquellos asociados con Redes de chía, Microsoft DeepSpeedy PyTorchson susceptibles a la inyección de código malicioso a través de ejecutores de GitHub Actions autohospedados.