Quand les étiquettes deviennent dangereuses : la deuxième attaque contre Trivy expose les références et les secrets CI / CD

Publié 6 min de lectura 119 lecture

La chaîne d'approvisionnement logicielle a encore démontré sa fragilité lorsque Trivy, le populaire scanner de vulnérabilité open source maintenu par Aqua Security, a subi un second engagement en quelques semaines qui a permis la distribution de code malveillant conçu pour voler des secrets d'environnement CI / CD. L'incident a tellement affecté le dépôt aquasécurité / trivy-action, utilisé pour exécuter Trivy dans GitHub Actions, comme un aquasecurity / configuration-trivy, ce qui facilite la configuration d'une version spécifique du scanner dans les flux de travail.

Selon l'enquête publique, l'agresseur a réussi à réécrire la plupart des étiquettes de version dans le dépôt d'action officiel et à les pointer vers des engagements malveillants qui comprenaient un voleur de lettres de créances écrit en Python. En modifiant les balises, les attaquants ont transformé des références de version soi-disant fiables en vecteur de distribution de malware, qui a permis l'exécution de la charge utile au sein des coureurs GitHub Actions et l'extraction des informations sensibles présentes dans ces environnements.

Quand les étiquettes deviennent dangereuses : la deuxième attaque contre Trivy expose les références et les secrets CI / CD
Image générée avec IA.

Le logiciel malveillant a été conçu pour rechercher et recueillir un large éventail de secrets: variables d'environnement, clés SSH, identifiants de fournisseur de cloud, identifiants de base de données, configurations Docker, jetons Kubernetes et même des paires de clés cryptomonéda et de pièces associées à des validateurs Solana. Après avoir recueilli ces informations, le code les a chiffrés et a essayé de les envoyer à un serveur contrôlé par l'attaquant; comme mécanisme d'urgence, si l'exfiltration directe a échoué, le malware a essayé de publier les données dans un dépôt public sous le compte GitHub de la victime en utilisant un jeton volé.

Cet épisode est la suite d'un incident précédent qui a impliqué un robot autonome surnommé hackerbot-claw, qui a explosé l'actionTirer _requête _ ciblepour obtenir un jeton d'accès personnel (PAT) puis l'utiliser pour publier des versions malveillantes et modifier l'infrastructure du projet. Aqua Security elle-même a reconnu que, bien que les secrets et les jetons aient été tournés après cette intrusion initiale, le confinement n'était pas complet et certains titres de compétence engagés pouvaient rester actifs pendant la nouvelle manipulation. Vous pouvez en savoir plus sur la chronologie et la réponse de l'entreprise dans la discussion officielle de GitHub: communication de Aqua.

Plusieurs sociétés de sécurité ont analysé le code malveillant. Les rapports techniques indiquent que le voleur opère par étapes claires: il recueille d'abord des données sensibles à partir de la mémoire du processus de coureur et du système de fichiers; puis il numérote le matériel volé; et essaie enfin de le transmettre à un domaine contrôlé par l'attaquant (identifié dans les rapports comme scan.aquasecurtiy [.]org) ou, si cela ne fonctionne pas, utilise le jeton capturé pour télécharger l'information dans un dépôt public appelé «tpcp-docs». D'autres rapports et descriptions techniques sont disponibles sur les blogs de recherche tels que: Socket, Wiz et Sécurité des étapes.

En termes d'attribution, il y a des indications qui pointent vers un acteur connu dans l'écosystème comme TeamPCP (également identifié par plusieurs alias). Une partie du code s'appelle "TeamPC Cloud furter" et les éléments techniques correspondent aux outils précédents attribués au groupe, bien que les chercheurs soulignent que cet auto-déplacement pourrait être un leurre. Pour un contexte plus large sur cette menace et ses tactiques dans les environnements nuageux, Elastic Security Labs a publié des documents de référence qui aident à comprendre le modus operandi d'acteurs comme TeamPCP : analyse technique de l'élastique.

Les implications pour les projets et les équipements qui dépendent des actions de GitHub sont claires : les références aux versions ou aux étiquettes ne peuvent plus être sûres si un acteur avec des identifiants valides réécrit des tags ou publie des versions malveillantes. En conséquence, les experts recommandent éviter les actions d'ancrage aux étiquettes de version mobile et, à la place, utiliser la SHA complète du commit s'assurer que l'action exécutée est exactement celle attendue. Cette recommandation technique a été soulignée par les chercheurs de Wiz comme une défense pratique contre le type d'empoisonnement par étiquette observé.

Si vous administrez des pipelines qui utiliseraient Trivy ou ses actions associées, l'intervention immédiate doit être préventive et forte. Aqua Security et les entreprises qui ont enquêté sur l'incident ont suggéré qu'une version sécurisée du logiciel (par exemple Trivy 0.69.3, trivy-action 0.35.0 et setup-trivy 0.2.6 selon les rapports) soit utilisée, pour traiter tous les secrets qui auraient pu être accessibles comme un engagement et pour procéder à la rotation en priorité. En outre, le blocage du domaine d'exfiltration et de l'adresse IP associée au niveau du réseau (mentionné 45.148.10 [.] 212 dans les analyses) peut aider à atténuer les tentatives de transmission de données en cours d'étude.

Quand les étiquettes deviennent dangereuses : la deuxième attaque contre Trivy expose les références et les secrets CI / CD
Image générée avec IA.

Au-delà des actions réactives, il y a d'importantes leçons organisationnelles : le processus de rotation des références doit être atomique et vérifiable, les permis accordés aux jetons et aux automatisations doivent être minimes par la conception, et les examens de sécurité des flux de travail doivent comprendre des contrôles pour détecter des changements inattendus dans les étiquettes ou les rejets. Pour mieux comprendre la persistance que les logiciels malveillants tentaient d'installer dans les systèmes Linux via systemd, la discussion sur ce mécanisme dans Red Canary fournit un contexte utile sur la façon dont les attaquants tentent de maintenir l'accès dans les équipements affectés: explication de la persistance avec systèmed.

Enfin, ce cas souligne que la sécurité des logiciels ne prend pas fin lors de la publication du code: l'infrastructure de livraison continue et les comptes privilégiés sont une cible critique. La combinaison d'examens techniques, de pratiques de gestion secrète et d'une configuration d'IC soucieuse de la sécurité est essentielle pour réduire le risque qu'une dépendance légitime devienne une porte arrière de vos secrets. Surveillez les mises à jour des responsables et des laboratoires de sécurité qui enquêtent sur l'incident et faites preuve de prudence si votre organisation a utilisé les versions touchées.

Sources recommandées et lectures : L'analyse par Socket de la nouvelle vague d'engagements ( Socket), le rapport technique de Wiz avec des détails de logiciels malveillants ( Wiz), suivre Step Security sur la version malveillante ( Sécurité des étapes) et la discussion ouverte d'Aqua à GitHub ( Aqua Sécurité).

Couverture

Autres

Plus de nouvelles sur le même sujet.