Erreurs de configuration d’intégration continue et de livraison continue (CI/CD) découvertes dans l’open source TensorFlow le cadre d’apprentissage automatique aurait pu être exploité pour orchestrer attaques de la chaîne d’approvisionnement.
Les erreurs de configuration pourraient être exploitées par un attaquant pour « compromettre la chaîne d’approvisionnement des versions de TensorFlow sur GitHub et PyPi en compromettant les agents de build de TensorFlow via une demande d’extraction malveillante », ont déclaré les chercheurs prétoriens Adnan Khan et John Stawinski. dit dans un rapport publié cette semaine.
L’exploitation réussie de ces problèmes pourrait permettre à un attaquant externe de télécharger des versions malveillantes sur le référentiel GitHub, d’exécuter du code à distance sur le programme d’exécution GitHub auto-hébergé et même de récupérer un jeton d’accès personnel (PAT) GitHub pour le serveur GitHub. utilisateur tensorflow-jenkins.
TensorFlow utilise GitHub Actions pour automatiser le pipeline de création, de test et de déploiement de logiciels. Les exécuteurs, qui font référence aux machines qui exécutent des tâches dans un workflow GitHub Actions, peuvent être auto-hébergés ou hébergés par GitHub.
« Nous vous recommandons d’utiliser uniquement des coureurs auto-hébergés avec des référentiels privés », GitHub Remarques dans sa documentation. « En effet, les forks de votre référentiel public peuvent potentiellement exécuter du code dangereux sur votre machine d’exécution auto-hébergée en créant une pull request qui exécute le code dans un workflow. »
En d’autres termes, cela permet à tout contributeur d’exécuter du code arbitraire sur le programme d’exécution auto-hébergé en soumettant une pull request malveillante.
Cependant, cela ne pose aucun problème de sécurité avec les exécuteurs hébergés sur GitHub, car chaque exécutant est éphémère et constitue une machine virtuelle propre et isolée qui est détruite à la fin de l’exécution de la tâche.
Praetorian a déclaré avoir été en mesure d’identifier les flux de travail TensorFlow exécutés sur des coureurs auto-hébergés, trouvant par la suite demandes de tirage à la fourche des contributeurs précédents qui ont automatiquement déclenché les flux de travail CI/CD appropriés sans nécessiter d’approbation.
Un adversaire cherchant à pirater un dépôt cible pourrait donc corriger une faute de frappe ou apporter une modification mineure mais légitime au code, créer une demande d’extraction pour celui-ci, puis attendre que la demande d’extraction soit fusionnée pour devenir contributeur. Cela leur permettrait alors d’exécuter du code sur le coureur sans déclencher de signal d’alarme en créant une demande d’extraction malveillante.
Un examen plus approfondi des journaux de flux de travail a révélé que le programme d’exécution auto-hébergé n’était pas seulement non éphémère (ouvrant ainsi la porte à la persistance), mais également que le GITHUB_TOKEN les autorisations associées au flux de travail étaient accompagnées d’autorisations d’écriture étendues.
« Parce que le GITHUB_TOKEN avait le Contenu : autorisation d’écritureil pourrait télécharger des versions sur https://github[.]com/tensorflow/tensorflow/releases/ », ont déclaré les chercheurs. « Un attaquant qui aurait compromis l’un de ces `GITHUB_TOKEN pourrait ajouter ses propres fichiers aux Release Assets. »
En plus de cela, les autorisations contents:write pourraient être utilisées pour envoyer du code directement vers le référentiel TensorFlow en injectant secrètement le code malveillant dans un branche de fonctionnalités et le fusionner dans la branche principale.
Ce n’est pas tout. Un acteur malveillant pourrait voler l’AWS_PYPI_ACCOUNT_TOKEN utilisé dans le flux de travail de publication pour s’authentifier auprès du registre Python Package Index (PyPI) et télécharger un fichier Python .whl malveillant, empoisonnant ainsi le package.
« Un attaquant pourrait également utiliser les autorisations de GITHUB_TOKEN pour compromettre le secret du référentiel JENKINS_TOKEN, même si ce secret n’a pas été utilisé dans les flux de travail exécutés sur les exécuteurs auto-hébergés », ont déclaré les chercheurs.
Suite à une divulgation responsable le 1er août 2023, les lacunes ont été corrigées par les responsables du projet à compter du 20 décembre 2023, en exigeant l’approbation des flux de travail soumis à partir de toutes les requêtes fork pull et en modifiant les autorisations GITHUB_TOKEN en lecture seule pour les flux de travail exécutés sur coureurs auto-hébergés.
« Les attaques CI/CD similaires sont en augmentation à mesure que de plus en plus d’organisations automatisent leurs processus CI/CD », ont déclaré les chercheurs.
« Les entreprises d’IA/ML sont particulièrement vulnérables, car bon nombre de leurs flux de travail nécessitent une puissance de calcul importante qui n’est pas disponible dans les exécuteurs hébergés sur GitHub, d’où la prévalence des exécuteurs auto-hébergés. »
Cette divulgation intervient alors que les deux chercheurs ont révélé que plusieurs référentiels GitHub publicsy compris ceux associés à Réseaux Chia, Microsoft DeepSpeedet PyTorchsont susceptibles d’être injectés de code malveillant via des exécuteurs GitHub Actions auto-hébergés.