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, il 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 invité à patcher en tant que priorité en cas d'urgence. Si cette découverte n'était pas 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 passé 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 de marionnettes aient érodé la confiance en le propriétaire bénévole du projet, Lasse Collin :

‍

‍

Ce scénario inhabituel est un excellent exemple d'une personne hautement technique qui est toujours 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 basée sur les rôles. C'était uniquement grâce à la curiosité et à la rapidité 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 Registre du NIST. Initialement considéré comme permettant le contournement de l'authentification SSH, une enquête plus approfondie a révélé qu'il 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 fait de grands efforts pour masquer le package 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 Chapeau rouge détaillé, si les circonstances s'y prêtent, cette interférence pourrait potentiellement permettre à un attaquant de rompre l'authentification SSHD et d'obtenir un accès non autorisé à distance à l'ensemble du système.

‍

Microsoft, entre autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme 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 stopper une attaque de cette nature s'ils n'ont pas un sens aigu de la sécurité, de solides connaissances en matière de sécurité et un soupçon de paranoïa. Il s'agit presque d'exiger un état d'esprit d'acteur de la menace. Cependant, une considération principale doit toujours se concentrer sur les dépôts de code source qui sont contrôlé 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 faut (devrait) tout un village pour maintenir un logiciel sécurisé

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 ridicule 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 de Secure Code Warrior.