GitHub Actions compromis : plus de peur que de mal ?

Prière d'épingler les actions tierces à des hashs de commits plutôt qu'à des étiquettes de versions.

Cette bonne pratique destinée à renforcer la sécurité de GitHub Actions prend tout son sens après une attaque survenue la semaine passée. Sa cible : tj-actions/changed-files, qui permet d'identifier les modifications de fichiers dans des PR ou des commits et d'effectuer des tâches en conséquence.

Le 14 mars, cette action s'est mise à télécharger et à exécuter un script Python malveillant. Son rôle : pour chaque workflow, récupérer les secrets CI/CD dans la mémoire de l'exécuteur et les intégrer dans les journaux de build., avec un double encodage base64 pour éviter leur masquage automatique. Quiconque pouvait alors, sur les dépôts publics, accéder à ces secrets.

De nombreuses versions de l'action furent compromises. Environ 24 heures s'écoulèrent avant que GitHub ne la retire - et la restaure par la suite sans le code problématique.

Les secrets leakés, majoritairement éphémères

L'incident est traité comme une vulnérabilité. Il a son identifiant CVE, avec un score de base de 8,8 sur l'échelle CVSS v3. Pour en arriver là, l'attaquant a semble-t-il compromis, de la même manière, une autre action : reviewdog/action-setup. Cela lui aurait permis d'exfiltrer un PAT (personal access token) utilisé par un bot disposant d'un accès privilégié à tj-actions/changed-files.

"Plus de 23 000 dépôts" utilisaient tj-actions/changed-files au moment de l'attaque, avaient affirmé ceux qui l'avaient découverte. Moins de 1 % auraient été affectés au final, à en croire les données d'Endor Labs.

Ce spécialiste de la gestion des dépendances compte plus précisément 218 dépôts victimes. Le tout sur une base moindre que celle initiatiement annoncée : dans l'intervalle de compromission, ils auraient été environ 5000 (sur quelque 4000 organisations) à pointer effectivement vers l'action par l'intermédiaire de fichiers YAML. Un nombre possiblement sous-estimé, reconnaît toutefois Endor Labs. D'une part, parce que GitHub code search, dont il s'est servi, se limite aux branches par défaut (généralement main/master). De l'autre, parce que ses recherches n'ont englobé que les définitions de workflows ayant une dépendance directe à l'action.

Sur ces quelque 5000 repos, 614 ont exécuté, dans l'intervalle en question, au moins un workflow affecté. Les 218 qui ont leaké des secrets ont surtout exposé des jetons d'accès d'installation. Moyennement intéressants pour des attaquants vu leur durée de vie limitée : 24 heures maximum, avec expiration lorsque le job se termine. Ont toutefois filtré quelques identifiants Docker, Terraform, Confluence ou AWS.

Illustration principale © MichaelVi - Adobe Stock