La porte dérobée XZ Utils sous Linux met en évidence un problème plus vaste de sécurité de la chaîne d'approvisionnement, et nous avons besoin de plus que de l'esprit communautaire pour le tenir en échec.

Le secteur de la cybersécurité a une fois de plus été placé en état d'alerte après la découverte d'une compromission insidieuse de la chaîne d'approvisionnement en logiciels. La vulnérabilité, qui affecte la bibliothèque de compression de données XZ Utils fournie avec les principales distributions Linux, est enregistrée sous la référence CVE-2024-3094 et se résume à une porte dérobée délibérément insérée par un mainteneur de système bénévole autrefois digne de confiance. Permettant l'exécution de code à distance (RCE) dans certains cas s'il est exploité avec succès, il s'agit d'un problème de haute sévérité pouvant causer de sérieux dommages dans les processus de construction de logiciels établis.

Heureusement, un autre mainteneur a découvert cette menace avant que le code malveillant n'entre dans les versions stables de Linux, mais cela pose toujours un problème pour ceux qui ont commencé à utiliser les versions 5.6.0. et 5.6.1. de XZ Utils dans le cadre de Fedora Rawhide, et les organisations sont invitées à le patcher en priorité d'urgence. Si cette découverte n'était pas faite à temps, le profil de risque en ferait l'une des attaques de la chaîne d'approvisionnement les plus dévastatrices jamais enregistrées, éclipsant peut-être même SolarWinds.

La dépendance à l'égard des bénévoles de la communauté pour la maintenance des systèmes critiques est largement documentée, mais rarement discutée jusqu'à ce que des problèmes à fort impact tels que cet incident remontent à la surface. Bien que leur travail infatigable soit essentiel à la maintenance des logiciels libres, cet incident souligne la nécessité de mettre sérieusement l'accent sur les compétences et la sensibilisation à la sécurité au niveau des développeurs, sans parler des contrôles d'accès renforcés autour des dépôts de logiciels.

Qu'est-ce que la porte dérobée XZ Utils, et comment l'atténuer ?

Le 29 mars, Red Hat a publié une alerte de sécurité urgente pour informer les utilisateurs de Fedora Linux 40 et Fedora Rawhide que les dernières versions des outils et bibliothèques de compression "XZ" contiennent un code malveillant qui semble avoir été conçu pour faciliter l'accès de tiers non autorisés. La manière dont ce code malveillant a été injecté fera probablement l'objet d'une étude approfondie à l'avenir, mais il s'agit d'un exercice d'ingénierie sociale sophistiqué, patient et long de plusieurs années de la part de l'acteur de la menace, un attaquant pseudonyme appelé "Jia Tan". Cet individu a passé d'innombrables heures à gagner la confiance d'autres mainteneurs, apportant des contributions légitimes au projet XZ Utils et à la communauté pendant plus de deux ans, finissant par obtenir le statut de "mainteneur de confiance" après que de multiples comptes sockpuppet aient érodé la confiance dans le propriétaire bénévole du projet, Lasse Collin :

‍

‍

Ce scénario inhabituel est l'exemple même d'une personne hautement technique qui est victime de tactiques généralement réservées à des personnes moins averties, ce qui montre la nécessité d'une formation de sensibilisation à la sécurité précise et axée sur les rôles. Ce n'est que grâce à la curiosité et à la rapidité d'esprit d'Andres Freund, ingénieur logiciel chez Microsoft et responsable de PostgreSQL, que la porte dérobée a été découverte et que les versions ont été retirées, mettant ainsi un terme à ce qui aurait pu être l'attaque de la chaîne d'approvisionnement la plus dévastatrice de l'histoire récente.

La porte dérobée elle-même est officiellement répertoriée comme une vulnérabilité de la plus haute gravité possible dans le registre du NIST. Initialement considérée comme permettant le contournement de l'authentification SSH, une enquête plus approfondie a révélé qu'elle permettait l'exécution de code à distance non authentifié sur les systèmes Linux vulnérables, y compris Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed et certaines versions de Debian.

Jia Tan semble s'être donné beaucoup de mal pour obscurcir le paquet malveillant qui, lorsqu'il se construit au cours du processus de construction, entrave l'authentification dans SSHd par l'intermédiaire de systemd.Comme l'a expliqué Red Hat, dans les bonnes circonstances, cette interférence pourrait potentiellement permettre à un attaquant de rompre l'authentification SSHd et d'obtenir un accès distant non autorisé à l'ensemble du système.

‍

Microsoft, entre autres, a publié des conseils complets sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets. L'action immédiate recommandée par la CISA est que les développeurs et les utilisateurs concernés rétrogradent XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.

Il est incroyablement difficile de prévenir ce type d'attaque - en particulier lors de l'utilisation de composants open-source dans les logiciels - car il y a très peu d'assurance et de transparence sur la sécurité de la chaîne d'approvisionnement. Nous avons déjà combattu les failles accidentelles dans la chaîne d'approvisionnement des logiciels, mais ce risque s'est accru pour inclure les bogues de sécurité délibérément mis en place avec malveillance pour compromettre la sécurité des logiciels libres.

La plupart des développeurs ne seront pas en mesure d'arrêter une attaque de cette nature s'ils ne sont pas très sensibilisés à la sécurité, s'ils n'ont pas de bonnes connaissances en la matière et s'ils n'ont pas une bonne dose de paranoïa. Il s'agit presque d'un cas où il faut avoir l'état d'esprit d'un acteur de la menace. Cependant, une considération principale devrait toujours être centrée sur les dépôts de code source qui sont contrôlés en interne (c'est-à-dire qui ne sont pas des sources ouvertes). Ils ne devraient être accessibles qu'aux personnes ayant des compétences vérifiées et pertinentes en matière de sécurité. Les professionnels de l'AppSec peuvent envisager une configuration telle que des contrôles de sécurité au niveau de la branche, permettant uniquement aux développeurs qualifiés en matière de sécurité d'apporter des modifications à la branche principale finale.

Les mainteneurs bénévoles sont des héros, mais il faut un village pour assurer la sécurité des logiciels.

Pour ceux qui n'appartiennent pas au domaine de l'ingénierie logicielle, l'idée qu'une communauté de bénévoles enthousiastes maintienne minutieusement des systèmes critiques pendant leur temps libre est un concept difficile à saisir, mais c'est la nature du développement open-source, et il continue d'être un domaine de risque critique pour les professionnels de la sécurité qui protègent la chaîne d'approvisionnement.

Les logiciels libres sont un élément essentiel de l'écosystème numérique de pratiquement toutes les entreprises, et les mainteneurs de confiance (dont la plupart agissent de bonne foi) sont vraiment héroïques dans leur poursuite désintéressée du progrès technologique et de l'intégrité, mais il est absurde de les laisser livrer en vase clos. En ces temps centrés sur DevSecOps, la sécurité est une responsabilité partagée, et chaque développeur doit être armé des connaissances et des outils adéquats pour naviguer dans les problèmes de sécurité qu'il est susceptible de rencontrer au cours de sa journée de travail. La sensibilisation à la sécurité et les compétences pratiques devraient être non négociables dans le processus de développement logiciel, et il appartient aux responsables de la sécurité d'influencer le changement au niveau de l'entreprise.
‍

‍Construisezdès aujourd'hui une culture de la sécurité florissante au sein de votre organisation grâce à une formation approfondie. Courses de Secure Code Warrior.