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

Le secteur de la cybersécurité est à nouveau en état d'alerte maximale après la découverte d'une compromission insidieuse dans la chaîne d'approvisionnement logicielle. La vulnérabilité, qui affecte la bibliothèque de compression de données XZ Utils incluse dans les principales distributions Linux, est enregistrée sous le code CVE-2024-3094 et se résume à une porte dérobée délibérément insérée par un mainteneur bénévole du système qui lui faisait autrefois confiance. Permettant dans certains cas l'exécution de code à distance (RCE) si elle est correctement exploitée, elle représente un problème très grave, car elle peut causer de sérieux dommages aux processus de création de logiciels établis.

Heureusement, un autre mainteneur a découvert cette menace avant que le code malveillant ne soit intégré dans les versions stables de Linux, mais cela reste un problème pour ceux qui ont commencé à exécuter 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é. Si cette découverte n'avait pas été faite à temps, le profil de risque en aurait fait l'une des attaques de la chaîne d'approvisionnement les plus dévastatrices de l'histoire, surpassant 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 questions à fort impact, telles que cet incident, soient mises en lumière. Si leur travail inlassable est essentiel au maintien des logiciels open source, cela met en évidence la nécessité pour les développeurs d'accorder une attention particulière aux compétences et à la sensibilisation en matière de sécurité, sans oublier de renforcer les contrôles d'accès aux référentiels logiciels.

Qu'est-ce que la porte dérobée de XZ Utils et comment peut-on la contrer ?

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 bibliothèques et outils de compression « XZ » contiennent un code malveillant qui semble avoir été spécialement conçu pour faciliter l'accès non autorisé de tiers. 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 de plusieurs années de la part de l'auteur de la menace, un attaquant pseudonyme appelé « Jia Tan ». Cette personne a passé d'innombrables heures à gagner la confiance d'autres mainteneurs, en apportant des contributions légitimes au projet et à la communauté XZ Utils pendant plus de deux ans, et a finalement obtenu le statut de « mainteneur de confiance » après que plusieurs comptes fictifs 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 habituellement réservées à des personnes moins informées, ce qui démontre la nécessité d'une formation précise et axée sur les fonctions pour sensibiliser à la sécurité. C'est uniquement grâce à la curiosité et à la vivacité d'esprit d'Andrés Freund, ingénieur logiciel chez Microsoft et responsable de la maintenance de PostgreSQL, 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 la plus dévastatrice de la chaîne d'approvisionnement de ces derniers temps.

La porte dérobée elle-même est officiellement répertoriée comme une vulnérabilité de la plus haute gravité dans le registre du NIST. On pensait initialement qu'elle permettait de contourner l'authentification SSH, mais une enquête ultérieure a révélé qu'elle permettait l'exécution à distance de code non authentifié sur les 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 pris toutes les précautions possibles pour dissimuler le paquet malveillant qui, lorsqu'il est activé pour se construire seul pendant le processus de création, complique l'authentification dans SSHd via systemd. Comme Red Hat l'explique en détail, dans certaines circonstances, cette interférence pourrait permettre à un attaquant de contourner l'authentification SSHd et d'obtenir un accès à distance non autorisé à l'ensemble du système.

Microsoft, entre autres, a publié un guide complet sur l'analyse des systèmes à la recherche de cas d'exploitation et l'atténuation de leur effet. L'action immédiate recommandée par la CISA est que les développeurs et les utilisateurs concernés devraient passer à une version non compromise de XZ Utils, telle que XZ Utils 5.4.6 Stable.

Il est extrêmement difficile de prévenir ce type d'attaque, en particulier lorsque des composants open source sont utilisés dans les logiciels, car il existe très peu de garanties et de transparence en matière de 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 et inclut désormais des failles de sécurité créées délibérément à des fins malveillantes pour compromettre la sécurité de l'open source.

La plupart des développeurs ne seront pas en mesure de contrer une attaque de cette nature, à moins d'avoir une forte conscience de la sécurité, de solides connaissances en la matière et une certaine dose de méfiance. Il s'agit presque d'un cas où il est nécessaire d'adopter la mentalité d'un acteur malveillant. Cependant, une considération principale doit toujours se concentrer sur les référentiels de code source que nous contrôlons en interne (c'est-à-dire non open source). Ils ne devraient être accessibles qu'aux personnes possédant des compétences pertinentes et vérifiées en matière de sécurité. Les professionnels de la sécurité des applications pourraient envisager une configuration similaire à celle des contrôles de sécurité au niveau des succursales, qui ne permet qu'aux développeurs experts en sécurité d'apporter des modifications à la dernière branche principale.

Les mainteneurs bénévoles sont des héros, mais il faudrait un effort collectif pour assurer la sécurité d'un logiciel.

Pour ceux qui ne sont pas familiarisés avec le domaine de l'ingénierie logicielle, l'idée qu'une communauté dynamique de bénévoles assure minutieusement la maintenance de systèmes critiques pendant leur temps libre peut sembler difficile à appréhender. Cependant, c'est la nature même du développement open source, et cela reste un domaine à risque critique pour les professionnels de la sécurité qui protègent la chaîne d'approvisionnement.

Les logiciels open source sont un élément essentiel de l'écosystème numérique de pratiquement toutes les entreprises, et ceux qui en assurent la maintenance (dont la plupart agissent de bonne foi) sont véritablement héroïques dans leur quête désintéressée du progrès technologique et de l'intégrité, mais il est absurde de les laisser fonctionner de manière isolée. À l'ère du DevSecops, la sécurité est une responsabilité partagée, et tous les développeurs doivent disposer des connaissances et des outils appropriés pour résoudre les problèmes de sécurité auxquels ils sont susceptibles d'être confrontés dans leur travail quotidien. Les connaissances en matière de sécurité et les compétences pratiques ne devraient pas être négociables dans le processus de développement de logiciels, et il appartient aux responsables de la sécurité d'influencer le changement au niveau de l'entreprise.

Créez dès aujourd'hui une culture de sécurité prospère au sein de votre organisation grâce à des informations exhaustives. Cours Secure Code Warrior.