Github Actions Attack rend même les orgs de sécurité vulnérables

Les développeurs hébergeant des référentiels de code sur GitHub continuent d’utiliser les actions GitHub insérect, la configuration des flux de travail automatiques qui peuvent être exploités pour extraire les jetons d’authentification sensibles, préviennent les chercheurs.

Les risques de sécurité associés aux actions GitHub ne sont pas nouveaux. Pourtant, des chercheurs de Sysdig ont identifié des dizaines de projets vulnérables, y compris ceux des organisations de grande envergure de la sécurité et Splunk.

« Ces workflows contiennent souvent des secrets, tels que les clés API ou les informations d’identification, qui peuvent être utilisées pour dégénérer les privilèges ou se déplacer latéralement dans le référentiel, ou même dans toute l’organisation s’ils sont exfiltrés », a écrit les chercheurs de Sysdig dans un rapport cette semaine. «Malgré la disponibilité des outils, des techniques et de la recherche publique détaillant comment identifier et exploiter ces vulnérabilités, le niveau de maturité global de nombreux projets open source reste alarmant.»

Un vecteur d’attaque Sysdig a étudié impliquant des flux de travail GitHub Actions qui déclenchent sur le pull_request_target événement. Selon Sysdig, le vecteur d’attaque expose les secrets et un jeton GitHub secret avec des autorisations d’écriture au référentiel. Et parce que l’action s’exécute dans le référentiel de base, pas la fourche qui a déclenché la demande de traction, si elle est implémentée sans garanties, elle peut entraîner une prise de contrôle du référentiel.

«Alors que nous analysions les résultats, nous avons été surpris par le nombre de vulnérables pull_request_target Les flux de travail que nous avons découverts », ont écrit les chercheurs.« Vous pourriez supposer que ceux-ci étaient limités à des référentiels obscurs ou inactifs, mais ce n’était pas le cas. Nous avons trouvé plusieurs projets de haut niveau avec des dizaines de milliers d’étoiles utilisant toujours des configurations en insécurité. »

Les attaques des actions GitHub deviennent réelles

GitHub Actions est un service CI / CD (intégration continue et livraison continue) qui permet aux développeurs d’automatiser les builds et les tests de logiciels en configurant des workflows qui déclenchent lorsque des événements spécifiés se produisent, par exemple lorsque un nouveau code est engagé dans le référentiel. Les workflows, appelés actions, sont des instructions emballées dans un .yml Fichier qui s’exécute à l’intérieur des conteneurs virtuels, généralement sur l’infrastructure de GitHub, et renvoyez les binaires compilés, les résultats des tests, les journaux, etc.

Pour fonctionner, les workflows doivent être en mesure de cloner le référentiel et d’effectuer des actions contre elle. Pour permettre cela, le système crée et enregistre un GITHUB_TOKEN à l’intérieur du local .git dossier pour permettre l’exécution des commandes GIT authentifiées. Ce jeton est censé être éphémère et devrait cesser de fonctionner une fois le flux de travail terminé.

Pendant des années, les chercheurs ont montré comment les actions de Github peuvent être abusées, y compris par la typosquat, construisent des artefacts qui n’ont pas été frottés de secrets et l’empoisonnement des artefacts lors du transfert entre les workflows. Et ce ne sont pas seulement des attaques théoriques. En décembre, les attaquants ont réussi à compromettre le processus de construction de la bibliothèque Ultralytics Yolo AI sur GitHub via une vulnérabilité d’injection de script GitHub Actions. Cela a entraîné le téléchargement de versions empoisonnées de la bibliothèque dans le référentiel PYPI.

Déclencheur d’action de demande de traction dangereuse

Une demande de traction se produit lorsqu’un développeur soumet un nouveau code à partir de sa version fourchue d’un référentiel de code au référentiel principal pour l’inclusion. Les demandes de traction sont ensuite examinées et commentées par les développeurs du projet avant d’accepter la demande de validation.

Dans les actions GitHub, le pull_request Le déclencheur invite le flux de travail à s’exécuter dans le contexte de la branche fourchue, créant un GITHUB_TOKEN Cela n’a lu que l’accès au référentiel principal. Le pull_request_target Le déclencheur, cependant, invite le flux de travail à s’exécuter dans le contexte de la branche cible, généralement la branche principale, du référentiel, avec un accès complet à tous les secrets stockés dans le référentiel ainsi qu’un GITHUB_TOKEN qui a lu et rédigé les privilèges. Les développeurs doivent être prudents en utilisant ce déclencheur, en particulier avec les workflows qui tentent de vérifier, d’exécuter ou de créer du code à partir de la demande de traction, car le code peut être malveillant et aura accès aux secrets, aux jetons et aux autorisations du flux de travail.

La documentation des actions GitHub met en garde contre ce comportement risqué. Sysdig a constaté que de nombreux développeurs l’utilisent toujours de cette manière pour tester les modifications de code dans les demandes de traction.

Un exemple que Sysdig a trouvé était dans Spotripy, une bibliothèque Python open source pour interagir avec l’API Web Spotify. Le projet est assez populaire avec plus de 5 000 étoiles sur Github et près de 1 000 fourches.

Le flux de travail Spotripy integration_tests.yml déclenche pull_request_targetvérifier le code du référentiel de la demande de traction avant d’effectuer un pip install (Python Package Installer) Commande pour installer des dépendances.

Si un attaquant placerait un malveillant setup.py Dans leur référentiel, ils peuvent exécuter du code malveillant pendant le workflow pip install action. La preuve de concept des chercheurs a déployé un memdump.py script qui a extrait les informations d’identification de la mémoire, y compris SPOTIPY_CLIENT_ID, SPOTIPY_CLIENT_SECRETet le surempouli GITHUB_TOKEN avec des autorisations de lecture / écriture.

Les résideurs ont également ajouté des commandes de sommeil à leur code malveillant pour prolonger le temps d’exécution du flux de travail et donc la validité de la GITHUB_TOKEN Il pourrait donc être abusé avant son expiration. La vulnérabilité a été évaluée critique et a été attribuée CVE-2025-47928.

MITER et SPLONK RORGE REPO MISCONIFIGURATIONS

Un deuxième exemple notable a été la voiture à Mitre (référentiel cyber-analytique), qui héberge ironiquement une collection d’analyses, y compris les règles de détection et la logique, conçues pour aider les équipes de sécurité à identifier les comportements adversaires mappés dans le cadre de l’attr & ck de Mitre.

Ce référentiel comprenait un flux de travail similaire à celui de Spotripy, qui a été déclenché sur pull_request_target Pour vérifier le code de la demande de traction et émettre un pip install -r ./scripts/requirements.txt commande. Depuis le requirements.txt Le fichier fait partie du code vérifié, il était complètement sous le contrôle d’un attaquant potentiel.

«Encore une fois, nous avons réussi à exfiltrer le défaut par défaut GITHUB_TOKEN et d’autres secrets, réalisant finalement des privilèges élevés au sein du référentiel « , a déclaré l’équipe Sysdig. » Après avoir signalé la vulnérabilité à la mitre, il a été reconnu et rapidement fixé par l’équipe de Mitre. « 

Un troisième exemple était un référentiel appartenant à Splunk appelé Security_Content qui avait un workflow abusable similaire. Dans ce cas, l’extrait GITHUB_TOKEN a été limité à uniquement l’accès à lire, mais les chercheurs ont réussi à extraire d’autres informations d’identification du référentiel appelé APPINSPECTUSERNAME et APPINSPECTPASSWORD. Le problème a été résolu après avoir été signalé, mais la nature et la sensibilité des informations d’identification extraites ne sont pas claires.

Atténuations

Il existe plusieurs façons d’atténuer ces risques erronés. D’abord, pull_request_target doit être évité si possible et partout où les implications et les risques de sécurité ne sont pas entièrement compris. Les workflows qui s’exécutent de cette manière ne doivent pas consulter le code non fiable.

Si des workflows privilégiés sont toujours nécessaires, des tâches dangereuses telles que la vérification et l’exécution du code dangereuse doivent d’abord être effectuées dans des flux de travail improvisés qui passent ensuite les résultats validés à ceux privilégiés. Ceci est connu sous le nom de division du flux de travail et est une stratégie recommandée par GitHub.

Deuxième, GITHUB_TOKEN Les autorisations doivent être configurées pour être lues uniquement, comme ce fut le cas dans le référentiel de Splunk. Cela ne protégera pas d’autres informations d’identification exposées dans l’exécution du workflow, mais cela empêchera les attaquants d’obtenir des privilèges d’écriture sur le référentiel principal.

« Une atténuation à considérer est la configuration du flux de travail à exécuter uniquement lorsqu’une étiquette spécifique est affectée à la demande de traction, nécessitant efficacement la vérification manuelle par les responsables ayant un accès en écriture au référentiel », ont indiqué les chercheurs sysdig. «Étant donné que les contributeurs externes ne peuvent pas attribuer des étiquettes, cela garantit que les demandes de traction déclenchent le flux de travail après un examen manuel.»