Tags trompeurs et Impostor Commits: le nouveau vecteur d'attaque dans la chaîne d'approvisionnement logicielle

Dans un nouvel exemple de la façon dont la chaîne d'approvisionnement du logiciel reste un vecteur attrayant pour les attaquants, la vérification de l'action populaire de GitHub a été détectée. actions-cool / questions-aide, où les acteurs malveillants ont déplacé toutes les balises dans le dépôt pour les pointer vers un commettre un imposteur qui ne fait pas partie de l'histoire légitime du projet. Le résultat : tout workflow qui renvoie l'action par label ou par version au lieu d'un commit fiable SHA pourrait télécharger et exécuter du code malveillant dans le coureur GitHub Actions lors de la prochaine course.

La technique de commission impostor exploite une propriété moins connue des étiquettes : contrairement à une SHA irrévocable, une étiquette peut être réassignée par quiconque contrôle le dépôt ou une fourche malveillante. Dans ce cas, le code injecté télécharge le Bun runtime, essaie de lire le Runner. Worker traite la mémoire pour extraire les identifiants présents dans l'environnement CI / CD et envoie les données à un serveur contrôlé par l'attaquant ("t.m-kosche [.] com"). Selon la première analyse, la même tactique a affecté un autre dépôt connexe, actions-cool / maintien-un-comment, et l'infrastructure d'exfiltration relie cet incident à une vague précédente qui a attaqué les paquets npm dans l'écosystème @ antv, suggérant une possible opération coordonnée sur plusieurs fronts.

Les implications pour les organisations et les projets libres sont claires et profondes : il a été démontré que les intégrations CI / CD peuvent devenir un vecteur direct pour l'extraction de secrets. GitHub Tokens, identifiants de cloud, clés API et autres secrets utilisés dans les workflows automatisés peuvent être lus et exfiltrés si un acteur parvient à exécuter un code arbitraire à l'exécution. En outre, la facilité de diffuser l'engagement - modifier les balises que de nombreuses actions utilisent par défaut - grossit la portée des dommages potentiels.

La défense contre de telles attaques devrait combiner des changements techniques immédiats et des politiques plus larges de gouvernance des logiciels. Dès que possible, examiner tous les flux de travail utilisant des actions de tiers et remplacer toute référence non solide (p. ex. utiliser « v1 » ou une étiquette) par un engagement connu et vérifié SHA. GitHub propose des recommandations et des guides pour durcir les actions de GitHub qui expliquent les bonnes pratiques telles que l'épinglement aux SHA, la limitation des permis de travail et la protection des secrets. https: / / docs.github.com / fr / actions / guides de sécurité / actions de sécurité-durcissement-pour-github.

La rotation des références et le confinement sont des étapes indispensables une fois l'exposition possible détectée. Si un dépôt ou un workflow potentiellement vulnérable a fonctionné depuis la publication de la commission d'imposteur, prendre l'engagement et tourner les jetons et les clés utilisés par ces workflows est la mesure prudente. Parallèlement, le trafic de sortie vers des domaines suspects devrait être bloqué dans la résolution DNS et dans les pare-feu de réseau interne afin d'empêcher que les données continuent à sortir pendant qu'elles font l'objet d'une enquête.

Sur le plan stratégique, cet incident renforce la nécessité d'adopter des pratiques plus robustes en matière d'intégrité de la chaîne d'approvisionnement, comme le modèle SLSA (Supply-chain levels for Software artefacts), qui propose des contrôles pour assurer la provenance et l'immutabilité des artefacts : https: / / slsa.dev /. En outre, mettre en œuvre l'authentification fédérée sans secrets intégrés (p. ex. OIDC pour les fournisseurs de cloud), les coureurs d'exécution avec moins de privilèges et de temps, et des politiques strictes d'examen et d'approbation pour l'inclusion d'actions de tiers, réduit la zone d'exposition.

Pour les équipes qui gèrent des projets open source ou l'infrastructure d'IC dans les entreprises, il convient également de vérifier l'utilisation des étiquettes et des fourchettes qui ont accès à des versions de publication, et d'encourager les pipelines qui n'exposent pas les secrets à des actions de tiers. La chaîne d'approvisionnement et les outils de numérisation de réputation pour les paquets et les actions, ainsi que les moniteurs de comportement anormal dans les coureurs - par exemple, les téléchargements inhabituels de binaires tels que Bun ou les pics de trafic sortant vers de nouveaux domaines - aident à détecter les détections précoces.

Enfin, la leçon opérationnelle est que la sécurité de la chaîne d'approvisionnement nécessite à la fois des contrôles techniques et une culture organisationnelle qui traite des secrets et des dépendances des tiers et des éléments de risque critique. Si votre organisation exécute des workflows touchés, agissez déjà : identifiez les références aux actions-cool et autres actions de tiers, remplacez les étiquettes par des SHA vérifiés, retirez et renouvelez les identifiants exposés et resserrez les autorisations de vos pipelines. La prévention et la réponse rapide sont la différence entre une interruption gérable et une filtration à fort impact.