La porte dérobée de 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 l'esprit communautaire pour le maîtriser.

Le secteur de la cybersécurité a de nouveau été placé en état d'alerte suite à la découverte d'une compromission insidieuse de la chaîne d'approvisionnement logicielle. 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 CVE-2024-3094 et se résume à une porte dérobée délibérément insérée par un mainteneur volontaire du système autrefois fiable. Autorisant l'exécution de code à distance (RCE) dans certains cas s'il est exploité avec succès, elle représente un problème très grave susceptible de provoquer de graves dommages dans les processus de création de logiciels établis.

Heureusement, un autre responsable a découvert cette menace avant que le code malveillant n'entre dans les versions stables de Linux, mais elle pose toujours un problème à 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 à appliquer le correctif en priorité en cas d'urgence. Si cette découverte n'avait pas été faite à temps, le profil de risque en ferait l'une des attaques les plus dévastatrices jamais enregistrées sur la chaîne d'approvisionnement, éclipsant peut-être même SolarWinds.

La dépendance à l'égard des bénévoles communautaires pour la maintenance des systèmes critiques est largement documentée, mais rarement abordée avant que des problèmes à fort impact tels que cet incident ne fassent surface. Bien que leur travail inlassable soit essentiel à la maintenance des logiciels libres, cela met en évidence la nécessité de mettre sérieusement l'accent sur les compétences en matière de sécurité et de sensibilisation au niveau des développeurs, sans oublier de renforcer les contrôles d'accès aux dépôts de logiciels.

Qu'est-ce que la porte dérobée XZ Utils et comment est-elle atténuée ?

Le 29 mars, Red Hat a publié une alerte de sécurité urgente pour informer les utilisateurs de Fedora Linux 4.0 et de Fedora Rawhide que les dernières versions des outils de compression et des bibliothèques « XZ » contiennent du code malveillant qui semble avoir été spécialement conçu pour faciliter l'accès non autorisé à des tiers. La manière dont ce code malveillant a été injecté fera probablement l'objet d'études approfondies à l'avenir, mais il s'agit d'un exercice d'ingénierie sociale sophistiqué, patient et long de la part de l'acteur de la menace, un attaquant pseudonyme appelé Jia Tan. Cette personne a consacré d'innombrables heures à gagner la confiance des autres responsables, à apporter des contributions légitimes au projet et à la communauté XZ Utils pendant plus de deux ans, pour finalement obtenir le statut de « mainteneur de confiance » après que plusieurs comptes fantômes aient érodé la confiance envers le propriétaire bénévole du projet, Lasse Collin :

‍

‍

Ce scénario inhabituel illustre parfaitement comment une personne hautement qualifiée sur le plan technique peut être victime de tactiques généralement réservées à des personnes moins averties, ce qui souligne la nécessité d'une formation de sensibilisation à la sécurité précise et basée sur les rôles. C'est uniquement grâce à la curiosité et à la vivacité d'esprit de l'ingénieur logiciel Microsoft et du responsable de PostgreSQL, Andrés Freund, que la porte dérobée a été découverte et que les versions ont été annulées, mettant ainsi fin à ce qui aurait pu être l'attaque de chaîne d'approvisionnement la plus dévastatrice de l'histoire récente.

La porte dérobée elle-même est officiellement considéré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ée sur des systèmes Linux vulnérables, notamment Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed et certaines versions de Debian.

Jia Tan semble avoir déployé des efforts considérables pour dissimuler le paquet malveillant qui, lorsqu'il est déclenché pour se construire pendant le processus de génération, entrave l'authentification dans SSHD via systemd. Comme l'a expliqué Chapeau rouge, si les circonstances s'y prêtent, cette interférence pourrait potentiellement permettre à un attaquant de contourner l'authentification SSHD et d'obtenir un accès non autorisé à distance à l'ensemble du système.

Microsoft, entre autres, a publié des directives complètes sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets. La mesure immédiate recommandée par la CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, telle que XZ Utils 5.4.6 Stable.

Il est extrêmement difficile de prévenir ce type d'attaque, en particulier lorsqu'il s'agit d'utiliser des composants open source dans les logiciels, car la sécurité de la chaîne d'approvisionnement est très limitée et peu transparente. Nous avons déjà combattu des failles accidentelles dans la chaîne d'approvisionnement logicielle, mais ce risque s'est accru et inclut désormais des bogues de sécurité délibérément implantés dans le but de compromettre la sécurité des logiciels libres.

La plupart des développeurs ne seront pas en mesure de contrer une attaque de cette nature s'ils ne possèdent pas un sens aigu de la sécurité, de solides connaissances en matière de sécurité et une certaine dose de méfiance. Il s'agit presque d'exiger un état d'esprit de menaçant. Cependant, une considération principale doit toujours se concentrer sur les dépôts de code source qui sont contrôlés en interne (c'est-à-dire non open source). Ils ne devraient être accessibles qu'aux personnes possédant des compétences de sécurité pertinentes et vérifiées. 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 expérimenté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 est nécessaire (il serait souhaitable) de mobiliser l'ensemble de la communauté pour assurer la sécurité d'un logiciel.

Pour ceux qui ne travaillent pas dans le domaine du génie logiciel, il est difficile de comprendre qu'une communauté dynamique de bénévoles entretienne minutieusement des systèmes critiques à leur rythme, mais c'est la nature du développement open source, qui continue de représenter un risque critique pour les professionnels de la sécurité qui protègent la chaîne d'approvisionnement.

Les logiciels libres constituent un élément essentiel de l'écosystème numérique de pratiquement toutes les entreprises, et les responsables de confiance (dont la plupart agissent de bonne foi) font preuve d'un véritable héroïsme dans leur quête désintéressée du progrès technologique et de l'intégrité, mais il est inapproprié de les laisser livrer de manière isolée. En ces temps centrés sur DevSecOps, la sécurité est une responsabilité partagée, et chaque développeur doit disposer des connaissances et des outils adaptés pour gérer 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 ne devraient pas être 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.

Instaurez dès aujourd'hui une culture de sécurité florissante au sein de votre organisation grâce à Cours Secure Code Warrior.