xz porte dérobée : 5 Leçons
13 avr. 2024
Ingénierie
CVE-2024–3094 — également connu sous le nom de xz-backdoor ou xz-trojan — est la plus inquiétante attaque de la chaîne d'approvisionnement logicielle à ce jour.
Un développeur identifié comme Jia Tan (Github JiaT75) a utilisé l'ingénierie sociale pour entrer dans le projet open-source Tukaani et a gagné la confiance de la communauté au cours des années suivantes.
Jia a finalement obtenu le statut de mainteneur pour le projet XZ-Utils.
Enfin, Jia a utilisé son statut pour déployer une obfuscation intelligente dans le code source et les fichiers binaires afin de créer une porte dérobée dans les versions 5.6.0 et 5.6.1 d'XZ-Utils. S'il était resté non découvert jusqu'à son intégration aux principales distributions, des millions de versions de Debian et de Red Hat auraient pu être affectées.
Une chronologie bien écrite des événements est publiée ici.
xz est l'attaque de chaîne d'approvisionnement logicielle la plus avancée
Les attaques de la chaîne d'approvisionnement logicielle impliquent l'ingestion de code ou de composants malveillants à un niveau plus profond que l'application elle-même. Cette attaque sur la « chaîne d'approvisionnement » de la construction de logiciels aide à obtenir un avantage en matière de distribution, car plus d'un projet en aval peut utiliser la même chaîne d'approvisionnement.
Dans le passé, des compromissions ont ciblé des applications largement utilisées (par exemple, MOVEit — CVE-2023–34362), un composant partagé (par exemple, log4j) ou une partie de l'environnement de construction (par exemple, SolarWinds, Codecov).
D'autre part, le xz-backdoor commence par compromettre d'abord la liste des « mainteneurs » du projet. Cela a été fait en créant une identité spécifique à cet effet — JiaT75 (aucun enregistrement des contributions de cet utilisateur avant 2021), gagnant la confiance du propriétaire du projet au fil du temps, et appliquant finalement de l'ingénierie sociale pour mettre la pression sur le propriétaire du projet afin qu'il accepte cet utilisateur comme mainteneur.
Une fois dans un rôle de confiance, il est naturel que les examens de code aient un biais de confiance et puissent faire en sorte que même une simple obfuscation ait un long chemin à parcourir.
Le volet technique de l'ouverture de la porte dérobée est également astucieux. Il inclut l'utilisation de fichiers binaires corrompus pour éviter l'examen de code, le chargement de ces fichiers en tant que scripts à l'aide de séquences de commandes simples mais divisées, et la répartition de l'entrée de la porte dérobée totale sur de nombreux changements différents. Dans tout projet de taille importante, en rapide évolution ou à faible ressource, ceux-ci pourraient être manqués lors des examens de code par une pluralité d'équipes — sans parler du fait que le soumissionnaire est déjà un mainteneur « de confiance ».
En combinant ce qui précède, nous ne pouvons pas penser à une autre chaîne d'approvisionnement logicielle avec autant de couches de préparation avant l'exploitation.
Pourrait se produire maintenant ou bientôt à nouveau
De nombreuses parties du xz-backdoor étaient mises en œuvre en raison de la nature de confiance du mainteneur, qui avait été socialement manipulée au fil des ans.
Avec plus de 50 millions de projets open source actifs, la probabilité demeure élevée que des mainteneurs « dignes de confiance » attendent le bon moment pour introduire un changement malveillant ou l'ont déjà introduit mais restent indétectés.
Cela diffère de log4shell (CVE-2021–44228) ou d'une vulnérabilité équivalente, où les développeurs n'avaient pas imaginé d'exploitation spécifique dans la première mise en œuvre. Par conséquent, après la découverte, les chercheurs peuvent encore rapidement enquêter et faire remonter des vulnérabilités spécifiques.
En revanche, un mainteneur « de confiance » introduisant une exploitation connue agirait délibérément et, par conséquent, tenterait d'obscurcir les changements autant que possible. Pour cette raison, la première réaction du constructeur de Tukaani, Lasse Collin, était —
Je serais méfiant même des versions plus anciennes de xz jusqu'à preuve du contraire.
Aucun des outils de sécurité connus ne détecterait xz
Alors qu'Interlynk est un fournisseur d'outils de sécurité, nous n'avons pas vu de preuves claires expliquant pourquoi un outil ou une technologie spécifique pourrait détecter un tel changement à l'avance.
OpenSSF a d'abord suggéré que le Scorecard OpenSSF aurait une note basse pour les projets xz utils, ce qui est une affirmation vraie.
Cependant, des vérifications spécifiques seraient toujours ignorées au profit de la réputation des projets pour leur utilité de compression incroyablement utile et fiable. Je ne peux pas imaginer quels modèles SAST/DAST trouveraient problématiques avec cette approche, surtout en considérant que le script incriminé est pré-converti en un blob. Un changement de comportement à l'exécution pourrait générer un certain bruit, mais faire partie de `sshd` ne soulèvera probablement pas de suspicion dans chaque situation.
Nous comprenons le besoin de la communauté des fournisseurs de sécurité de réaffirmer leurs rôles dans cette conversation, mais nous croyons que la véritable conversation doit avoir lieu au sein des communautés open-source et peut être soutenue par des outils si nécessaire.
La racine de ce défi est que savoir si quelqu'un est un candidat Manchurian est un problème complexe car la preuve reste dans sa tête.
SBOM ne détectera pas de porte dérobée
Interlynk sécurise la chaîne d'approvisionnement logicielle en automatisant le flux SBOM. Dans le xz-backdoor, un SBOM aiderait à identifier quand et ce qui a changé à travers la chaîne d'approvisionnement, quelle version chaque composant utilise, et l'intégrité des composants (y compris les données de test).
De plus, Interlynk crée un score de risque basé sur la Scorecard OpenSSF elle-même, avec l'âge et l'utilisation du paquet, le nombre de mainteneurs, et quelques autres signaux. La version spécifique aurait commencé basse (5.4) et aurait augmenté en valeur au fil du temps (6.8 à la fin mai).
Cependant, cette information déclencherait des violations de politique si elle est configurée autour du risque mais sera probablement ignorée par les équipes de sécurité produit, compte tenu de la confiance acquise par le projet.
Donc, nous ne prétendons pas qu'un programme SBOM existant (ou tout autre outil de sécurité) aurait pu détecter l'intégration du xz-backdoor.
Comme suggéré, le SBOM n'est pas une solution miracle pour tous les risques de la chaîne d'approvisionnement logicielle. Cependant, il joue un rôle essentiel pour garantir l'intégrité et organiser les efforts de remédiation postérieure.
Mais le SBOM est une solution pour la remédiation.
Imagine que ce xz-backdoor ait été découvert fin juin au lieu de fin mars. D'ici là, il aurait probablement pénétré plusieurs distributions Linux et été installé sur des millions de serveurs.
Tous les responsables de la sécurité des produits et de DevOps connaissent la sensation de ce qui vient ensuite — répondre à des questions telles que :
Sommes-nous infectés ?
Quels produits et versions sont infectés ?
Comment les corrigeons-nous ?
Comment demandons-nous à nos fournisseurs s'ils sont infectés ?
Qu'en est-il de nos vendeurs ?
Comment prouvons-nous à nos équipes de conformité que cela est suivi ?
Ce n'est pas la première fois que cet exercice a lieu, et ce ne sera pas la dernière.
Cependant, avec SBOM, tout le suivi aurait pu être effectué dans une seule interface.
Tous les actifs avec SBOM sont mappés à la version spécifique du logiciel avec la version spécifique des composants.
Un plan de mise à jour mettrait à jour le SBOM avec lui et montrerait la version du composant passant à la version corrigée.
Un VEX accompagnant permettrait aux partenaires en amont et en aval de communiquer cela en temps réel.
Cela ne va pas s'arrêter, mais le SBOM est le fondement pour coordonner les efforts pour atténuer cela.
Nous sommes ici pour soutenir une communauté open-source saine, sûre et incroyable autour de nous.
Contactez-nous à hello@interlynk.io pour discuter.