Trivy et TeamPCP : failles critiques dans la chaîne logistique
Origines et historique
La compromission de Trivy, un scanner open source largement utilisé pour l'analyse d'images conteneurisées, a servi de point d'appui à une campagne coordonnée visant à affaiblir la chaîne logistique logicielle. Des acteurs identifiés comme TeamPCP ont exploité une technique appelée "Tag Poisoning" pour injecter des versions compromises et propager la menace jusque dans des pipelines CI/CD et des images en production¹.
Plusieurs composants et outils ont été impliqués ou ciblés durant cette campagne :
- Trivy : utilisé dans de nombreux pipelines pour détecter vulnérabilités et dépendances risquées.
- KICS : outil d'analyse d'infrastructure-as-code ciblé pour modifier des templates et ouvrir des surfaces d'attaque.
- LiteLLM : composant d'automatisation intégrant des modèles LLM, exploité pour introduire prompts malveillants et modifications automatiques.
- TeamPCP : acteur malveillant orchestrant une série d'attaques en chaîne, en profitant des failles de confiance entre artefacts et pipelines.
Cet incident rappelle qu'une compromission d'un outil considéré comme digne de confiance affecte directement toutes les builds qui s'y fient, et rend potentiellement suspects les artefacts produits par ces pipelines¹.
Fonctionnement technique
1) Prérequis et phase d'accès initial
La campagne commence généralement par la compromission d'un point de distribution ou d'un référentiel d'artefacts lié à Trivy. Les vecteurs observés incluent l'injection malveillante dans un artefact publié, la compromission d'un compte de publication ou l'usurpation d'un dépôt de tags/versions. Une fois la chaîne de publication affaiblie, l'attaquant peut pousser des versions altérées que les pipelines consomment automatiquement.
2) Tag Poisoning - définition et mécanisme
Le Tag Poisoning consiste à manipuler les tags et métadonnées qui identifient des artefacts (images, packages, releases) pour faire en sorte que des environnements automatisés récupèrent des versions compromises au lieu des versions prévues. Les méthodes observées comprennent :
- Publication d'images ou packages dotés de tags identiques à ceux employés par des builds légitimes.
- Altération des métadonnées pour forcer la mise en cache d'artefacts falsifiés par des scanners ou des proxys.
- Exploitation de politiques de résolution permissives qui acceptent des ranges de versions sans pinning strict.
Chaîne d'attaque typique :
- Compromission ou usurpation d'un flux fournissant Trivy.
- Publication d'une version manipulée du scanner ou d'un artefact consommé.
- Exécution de pipelines CI/CD intégrant cette version compromise.
- Altération silencieuse des artefacts produits par le scanner malveillant.
- Push d'artefacts compromis vers des registres internes ou externes.
- Déploiement d'images compromises exposant des services critiques.
3) Mécanismes d'escalade et pivot
Une fois le pipeline compromis, les actions possibles pour un attaquant sont nombreuses :
- Exfiltration de secrets présents en clair ou accessibles depuis le runner infecté.
- Compromission de comptes de service disposant d'accès aux registres d'artefacts et aux environnements de déploiement.
- Injection de modifications dans les templates IaC (Terraform, CloudFormation) pour ouvrir des accès persistants ou déployer des agents malveillants.
Les artefacts signés ou vérifiés de façon indépendante peuvent limiter certains pivots, mais ils ne remplacent pas une gouvernance stricte ni l'isolement des runners.
4) Indicateurs de compromission (IOCs)
Surveillez en priorité ces signaux :
- Publication de tags en dehors des fenêtres de publication habituelles ou avec des créateurs inhabituels.
- Signatures manquantes, invalides ou absentes sur des artefacts supposés signés.
- Divergences de hash entre l'image reconstruite localement et celle présente dans le registre.
- Téléchargements de dépendances non pinées lors d'exécutions CI/CD.
- Trafic sortant inhabituel depuis les runners vers des domaines externes non approuvés.
Une détection rapide passe par la corrélation des logs de build, des journaux réseau et des registres d'artefacts.
Études de cas
Cas 1 : Compromission d'un scanner SCA et propagation vers des images de production
Dans un cas concret, la compromission d'un scanner SCA a permis l'insertion d'une backdoor dans les images finales. Le binaire malveillant exfiltrait des secrets et tenait un canal de récupération. L'attaque est restée active plusieurs semaines car les scans externes classiques ne détectaient pas la modification interne introduite par le scanner compromis.
Contre-mesures appliquées : retrait immédiat des versions compromises, rotation complète des secrets, analyse forensique des images et rollback sur des artefacts antérieurs sains.
Cas 2 : Poisoning de tags sur un registre interne
Une version compromise de LiteLLM a été téléchargée depuis un registre interne, entraînant des modifications dans des templates Terraform automatiques. Les déploiements subséquents ont exposé des ressources critiques.
Leçons tirées : verrouillage strict des politiques de résolution des dépendances, quarantaine systématique des builds non vérifiés et validation manuelle des changements de versions pour les composants critiques.
Cas 3 : Chaînage vers des composants IA
Des prompts et configurations malveillantes ont été injectés dans des pipelines intégrant LiteLLM. Ce type d'altération peut entraîner des fuites d'informations sensibles vers des systèmes tiers ou la génération automatique d'instructions facilitant d'autres intrusions.
Risques principaux : fuite de données, exposition d'architectures internes, automatisation d'étapes d'attaque via des agents IA compromis.
Perspectives
La fréquence et la sophistication des compromissions d'outils de build exigent une révision immédiate des pratiques de gouvernance et de sécurité de la chaîne d'approvisionnement logicielle. Anticipez les évolutions suivantes dans les 12 à 24 mois :
- Adoption généralisée des signatures d'artefacts et des vérifications automatiques en pipeline, avec attestation de provenance des builds.
- Industrialisation des SBOM pour chaque build afin de connaître et contrôler précisément les composants inclus.
- Renforcement de la séparation et de l'isolation des runners CI/CD pour limiter la blast radius en cas de compromis.
- Politique de pinning stricte des versions et processus d'approbation formel pour tout changement de tag.
Le coût d'une compromission peut être multiplié par 10 à 50, rendant les mesures préventives non négociables pour les organisations exposées³.
Recommandations opérationnelles (actions immédiates)
- Exigez la signature de tous les artefacts critiques et validez ces signatures automatiquement dans le pipeline, idéalement via des solutions d'attestation.
- N'utilisez pas 'latest' ni des ranges permissifs ; appliquez un pinning strict et contrôlez toute mise à jour via un processus d'approbation.
- Isolez physiquement et logiquement les runners ayant accès aux secrets, et appliquez la politique du moindre privilège.
- Générez et conservez un SBOM pour chaque build et comparez-le avant déploiement pour détecter toute inclusion inattendue.
- Scannez les métadonnées et les tags des artefacts pour repérer des anomalies et automatiser des règles de quarantaine.
- Déployez des outils de monitoring réseau pour détecter des exfiltrations atypiques depuis les runners ou agents de build.
- Automatisez la rotation des secrets et planifiez une revalidation complète de l'intégrité après tout incident.
Face à la campagne attribuée à TeamPCP, la priorisation de ces mesures réduit fortement la surface d'exposition et la probabilité d'une propagation silencieuse des compromissions¹².
