GitHub piège Actions avec un paquet npm malveillant

Veracode a découvert un paquet npm malveillant pour Actions de GitHub utilisant le typosquatting pour berner les développeurs. Le spécialiste du partage de code a indiqué qu’il s’agissait d’une campagne menée par son équipe de red team.

Les outils de développement deviennent une cible de plus en plus importante pour les cybercriminels. Dans le catalogue de vecteurs, les paquets npm sont privilégiés comme le montre une analyse de Veracode sur un paquet malveillant usurpant l’identité du paquet officiel. Une fois téléchargé, il était programmé pour se déclencher pendant le processus de construction des référentiels appartenant à GitHub. Une fois exécuté dans un runner CI/CD, le payload capturait tous les jetons disponibles dans cet environnement de construction, puis utilisait ces identifiants pour publier des artefacts malveillants, usurpant ainsi l’identité de GitHub.

« Cet incident ne concerne pas seulement un paquet npm malveillant, il met en évidence la confiance aveugle que de nombreuses entreprises accordent à la supply chain logicielle moderne », a déclaré Randolph Barr, responsable de la sécurité des systèmes d’information (CISO) chez Cequence Security. « La plupart des entreprises concentrent leurs contrôles sur les environnements d’exécution, mais le pipeline CI/CD fonctionne souvent avec des privilèges plus élevés que n’importe quel développeur. Or, une seule dépendance typosquattée peut exécuter silencieusement du code pendant une compilation, accéder aux jetons du référentiel et usurper l’identité d’une organisation, comme a tenté de le faire cette attaque avec les propres référentiels de GitHub. »

Un exercice de red team selon GitHub

Comme l’ont indiqué les chercheurs de Veracode dans un blog, « le paquet malveillant a été téléchargé plus de 206 000 fois avant d’être détecté, et six versions au total ont été mises en ligne, aucune n’étant décelé par les produits antivirus courants ». Github affirme que les paquets ont été téléchargés en interne dans le cadre de ses efforts de red teaming. « Les paquets mentionnés dans le blog de Veracode faisaient partie d’un exercice étroitement contrôlé mené par la red team de GitHub », a déclaré un porte-parole du spécialiste du partage de code.

« GitHub prend la sécurité très au sérieux et teste régulièrement son niveau de sécurité à travers des exercices rigoureux et réalistes menés par la red team afin de garantir sa résilience face aux techniques actuelles des acteurs malveillants. À aucun moment, les systèmes ou les données de GitHub n’ont été mis en danger », précise la filiale de Microsoft.

Détournement du processus build de GitHub Actions

À première vue, le paquet « @acitons/artifact » semblait normal, avec des métadonnées le décrivant comme « actions artifact lib » et des URL de page d’accueil et de référentiel reflétant étroitement celles du projet GitHub légitime. En fait, celui-ci contenait un hook post-installation qui téléchargeait et exécutait un script shell obscurci nommé « harness ». L’analyse de Veracode a montré que ce script, compilé à l’aide d’un outil de compilation de scripts shell, contenait un kill switch temporel programmé pour se désactiver après le 6 novembre 2025, sans doute pour échapper à la détection après une brève période d’activité. Une fois invoqué, le script « harness » récupérait un fichier JavaScript (« verify.js ») qui vérifiait si l’environnement de compilation appartenait à GitHub et, si tel était le cas, à exfiltrer les jetons GitHub Action.

Ces jetons pouvaient ensuite être utilisés à mauvais escient pour usurper l’identité de GitHub et publier des versions malveillantes. « Le typosquatting est un vecteur de menace bien connu et en pleine expansion dans les cycles de développement logiciel, par lequel les attaquants publient des paquets portant des noms similaires à ceux de paquets officiels, puis attendent qu’une erreur se produise, amenant la victime à installer par erreur du code malveillant dans leur référentiel », a expliqué Boris Cipot, ingénieur senior en sécurité chez Black Duck. « Cette stratégie d’attaque est conçue pour exploiter les fautes de frappe et la nature automatisée des pipelines CI/CD. » M. Cipot ajoute que l’utilisation d’un hook post-installation et d’une charge utile obscurcie de courte durée montre qu’il s’agit d’une tentative délibérée de se fondre dans l’activité normale de compilation.

Enseignements en matière de défense

Barr a souligné que les privilèges élevés des pipelines CI/CD en font une cible idéale. Les attaquants qui compromettent un build runner peuvent injecter du code à la source, signer des versions avec des identifiants légitimes ou pousser des artefacts d’apparence authentique. Selon Boris Cipot, les mesures d’atténuation pourraient inclure des jetons à durée de vie limitée et à portée restreinte, avec des rotations régulières des secrets. L’analyse automatisée des paquets suspects à l’aide d’outils comme Socket.dev ou Phylum pourrait également aider à garder une longueur d’avance sur la menace. « Il existe d’autres moyens de vérifier l’authenticité des paquets, comme la validation des sommes de contrôle et les nouvelles normes comme Sigstore », a-t-il ajouté.

Jason Soroko, chercheur senior chez Sectigo, conseille aux équipes potentiellement touchées de réagir immédiatement. « Il faut rechercher @acitons et 8jfiesaf83 dans le code source, les fichiers lockfiles, les caches et les registres, puis mettre en quarantaine tous les runners qui les ont récupérés », a-t-il précisé. Celui-ci recommande aussi de « faire tourner tous les jetons et d’examiner les artefacts et l’historique de publication des paquets pour la période du 29 octobre au 6 novembre 2025. »

chevron_left
chevron_right