La chaîne d'approvisionnement du logiciel en contrôle: compromis Images trivy et références exposées

Publié 5 min de lectura 118 lecture

La sécurité du développement logiciel a de nouveau fait l'objet d'une attention particulière après une nouvelle vague d'attaques axées sur la chaîne d'approvisionnement : les versions échouées du scanner de vulnérabilité Trivy, distribué par Docker Hub, ont servi de vecteur pour filtrer les références et diffuser les logiciels malveillants au-delà de l'environnement original. La portée n'est pas limitée à une simple image engagée: les effets ont été ressentis dans les dépôts, les actions GitHub et les paquets d'écosystèmes open source.

Selon les chercheurs qui ont analysé la campagne, les dernières versions publiques fiables de Trivy dans Docker Hub datent de l'étiquette 0.69.3; immédiatement après, les images étiquetées comme 0.69.4, 0.69.5 et 0.69.6 ont été jugées malveillantes et retirées. Vous pouvez vérifier les étiquettes historiques sur la page du dépôt d'images officiel aquasec / trivy dans Docker Hub.

La chaîne d'approvisionnement du logiciel en contrôle: compromis Images trivy et références exposées
Image générée avec IA.

Le modèle d'attaque décrit par les analystes indique une escalade en chaîne : un acteur malveillant exploitait des lettres de créances engagées pour télécharger des versions de Trivy avec un voleur de lettres de créances embarquées, et a également réussi à injecter des changements dans deux actions GitHub liées au projet - celles qui facilitent l'intégration de Trivy dans les pipelines - qui ont multiplié la surface de l'infection dans les environnements CI / CD. Les détails techniques et les indicateurs d'engagement ont été documentés par l'équipe de Socket Security dans le présent rapport. sur les images de Trivy engagés.

Cette intrusion n'a pas été isolée : avec les pouvoirs exfiltrés, les attaquants ont réussi à compromettre les paquets dans l'enregistrement npm et à distribuer une menace autoréplicatrice connue sous le nom de CanisterWorm. Les chercheurs indépendants qui ont suivi la campagne ont attribué les actions à un acteur nommé TeamPCP, qui avait déjà manifesté de l'intérêt pour l'infrastructure cloud et les composants natifs tels que les API de Docker, les grappes Kubernetes et les services exposés.

L'impact a également touché l'organisation Aqua Security. Selon le suivi médico-légal publié par l'équipe OpenSourceMalware, 44 dépôts internes de l'organisation aquasec@-@ com à GitHub ont été renommés et exposés publiquement dans un intervalle de temps très court, suggérant une opération automatisée à travers un jeton engagé d'un compte de service. L'analyse technique disponible sur son blog explique comment un jeton persistant (du service "Argon-DevOps-Mgt") a servi de clé à l'écriture dans plusieurs organisations, amplifiant les dommages de la chaîne : analyse de l'engagement.

Des rapports techniques ont également documenté l'évolution des capacités du groupe attaquant : outre le vol de lettres de créance et la distribution de vers, des charges utiles conçues pour saboter des environnements ont été identifiées. Les chercheurs de l'entreprise Aikido décrivent un composant qui, selon les règles incluses dans son script, déploie privilégié DaemonSet dans chaque noeud Kubernetes et, dans les systèmes avec des détections géographiques orientées Iran, exécute la suppression de masse et les routines de redémarrage forcé. L'article technique d'Aikido tante comment ce fardeau se comporte et dans la séparation des actions selon l'emplacement de l'objectif: analyse de la charge utile et de son impact sur les K8.

S'il y a une leçon évidente à tirer de cet incident, c'est qu'un seul maillon faible de la chaîne d'approvisionnement (par exemple, un compte de services avec un jeton à long terme) peut avoir des conséquences en cascade. Les références persistantes et les permis trop larges sont précisément ce que les attaquants cherchent à exploiter pour déplacer latéralement et empoisonner les flux de travail automatisés..

Pour les équipes qui utilisent Trivy dans leurs pipelines, les recommandations immédiates sont évidentes : éviter les versions affectées, vérifier les exécutions récentes et s'engager si ces images ou actions ont été utilisées dans des processus critiques. Le dépôt de Trivy à GitHub et ses responsables ont publié des informations officielles sur la recherche et les versions sûres, il convient donc de contraster avec la source principale: Dépôt Trivy dans GitHub.

Au-delà du remplacement ou du blocage des images, la réponse devrait inclure des mesures d'hygiène d'identification : révoquer les jetons et les clés suspectes, réduire la durée de vie des jetons de service, revoir les permis attribués aux comptes automatisés et appliquer des principes moins privilégiés dans l'intégration interorganisationnelle. Il est également conseillé de renforcer le contrôle de l'accès aux API Docker (par exemple, éviter d'exposer le port 2375 sans authentification) et d'appliquer la segmentation réseau qui empêche un serveur engagé de diffuser des agents vers des sous-réseaux locaux.

La chaîne d'approvisionnement du logiciel en contrôle: compromis Images trivy et références exposées
Image générée avec IA.

Au niveau de l'organisation, il convient de compléter ces actions par la détection et la réponse : examiner les registres CI/CD à la recherche d'exécutions anormales, vérifier l'intégrité des artefacts déployés et utiliser les signatures et la vérification des sources pour les images en production. Les autorités et les équipes de sécurité publique ont publié des guides d'atténuation des risques dans la chaîne d'approvisionnement des logiciels; leur consultation peut aider à officialiser les politiques de contrôle des incidents et d'intervention, par exemple dans le répertoire des ressources de la CISA sur la gestion des risques dans la chaîne d'approvisionnement des logiciels ( CISA - Gestion des risques de la chaîne d'approvisionnement logicielle).

Il est important de se rappeler que dans de telles attaques il n'y a pas toujours une victime visible: l'organisation qui possède le projet concerné peut devenir une plate-forme involontaire pour engager des dizaines ou des centaines de consommateurs de son logiciel. La confiance dans les composants et les actions de tiers doit être validée en permanence et non assumée à vie.

Alors que les équipes médico-légales et les gestionnaires de plate-forme continuent de corriger les vecteurs et de publier des indicateurs d'engagement, les entreprises et les développeurs doivent prendre des mesures immédiates pour limiter l'impact et empêcher que de petites défaillances locales ne deviennent des lacunes massives. La chaîne d'approvisionnement des logiciels est aussi forte que le maillon le plus faible : minimiser ces faiblesses est maintenant une priorité incontournable.

Couverture

Autres

Plus de nouvelles sur le même sujet.