La porte dérobée dans XZ Utils souligne un problème plus large de sécurité de la chaîne d'approvisionnement, et il nous faut plus que l'esprit communautaire pour le contrer.

L'industrie de la cybersécurité a été placée en état d'alerte suite à la découverte d'une compromission insidieuse de la chaîne d'approvisionnement logicielle. La vulnérabilité, affectant la bibliothèque de compression de données XZ Utils intégrée aux principales distributions Linux, est répertoriée sous le code CVE-2024-3094 et consiste en une porte dérobée délibérément insérée par un mainteneur bénévole autrefois considéré comme fiable. Permettant dans certains cas l'exécution de code à distance (RCE) en cas d'exploitation réussie, il s'agit d'un problème de haute gravité capable de causer des dommages sérieux aux processus de construction logicielle établis.

Heureusement, un autre mainteneur a découvert cette menace avant que le code malveillant n'atteigne les versions stables de Linux, mais elle reste problématique pour ceux ayant commencé à utiliser les versions 5.6.0 et 5.6.1 de XZ Utils dans Fedora Rawhide. Les organisations sont invitées à appliquer un correctif en priorité absolue. Si cette découverte n'avait pas eu lieu à temps, le profil de risque en aurait fait l'une des attaques de chaîne d'approvisionnement les plus dévastatrices jamais enregistrées, surpassant peut-être même SolarWinds.

La dépendance envers les bénévoles pour maintenir des systèmes critiques est largement documentée, mais rarement discutée jusqu'à ce que des incidents de cette ampleur surviennent. Bien que leur travail inlassable soit essentiel à la maintenance des logiciels open source, cela souligne la nécessité d'insister sur les compétences et la sensibilisation à la sécurité au niveau des développeurs, sans oublier des contrôles d'accès renforcés autour des dépôts 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 40 et Fedora Rawhide que les dernières versions des outils et bibliothèques de compression « XZ » contiennent du code malveillant conçu pour faciliter l'accès non autorisé de tiers. La manière dont ce code a été injecté fera probablement l'objet d'études approfondies, mais il s'agit d'un exercice d'ingénierie sociale sophistiqué et patient, mené sur plusieurs années par un attaquant pseudonyme nommé « Jia Tan ». Cet individu a passé d'innombrables heures à gagner la confiance d'autres mainteneurs, apportant des contributions légitimes au projet XZ Utils pendant plus de deux ans, obtenant finalement le statut de « mainteneur de confiance » après que plusieurs comptes fictifs ont érodé la confiance envers le propriétaire du projet, Lasse Collin :

‍

‍

Ce scénario inhabituel est un exemple frappant d'une personne hautement technique tombant tout de même dans le piège de tactiques généralement réservées aux moins avertis, démontrant le besoin d'une formation à la sécurité précise et basée sur les rôles. C'est uniquement grâce à la curiosité et à la réactivité de l'ingénieur logiciel Microsoft et mainteneur PostgreSQL, Andres Freund, que la porte dérobée a été découverte et les versions annulées, stoppant ainsi ce qui aurait pu être l'attaque de chaîne d'approvisionnement la plus dévastatrice de mémoire récente.

La porte dérobée elle-même est officiellement suivie comme une vulnérabilité de la plus haute gravité dans le registre du NIST. Initialement pensée pour permettre 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 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é de grands efforts pour masquer le paquet malveillant qui, lorsqu'il est déclenché pour se construire pendant le processus de compilation, entrave l'authentification dans SSHd via systemd. Comme Red Hat l'a détaillé, dans les bonnes circonstances, cette interférence pourrait potentiellement permettre à un attaquant de briser 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 pour détecter les instances de l'exploit et en atténuer les effets. L'action immédiate recommandée par la CISA est que les développeurs et utilisateurs concernés rétrogradent XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.

Prévenir ce type d'attaque est incroyablement difficile, surtout lors de l'utilisation de composants open source, car il existe très peu d'assurance et de transparence sur la sécurité de la chaîne d'approvisionnement. Nous avons déjà combattu des failles accidentelles, mais ce risque s'est étendu aux bugs de sécurité délibérément plantés avec malveillance pour compromettre la sécurité open source.

La plupart des développeurs ne pourront pas arrêter une attaque de cette nature sans un sens aigu de la sensibilisation à la sécurité, des connaissances solides et une pointe de paranoïa. Il s'agit presque d'adopter l'état d'esprit d'un attaquant. Cependant, une considération majeure 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). Ceux-ci ne devraient être accessibles qu'aux personnes possédant des compétences en sécurité vérifiées et pertinentes. Les professionnels de l'AppSec pourraient envisager des contrôles de sécurité au niveau des branches, n'autorisant que les développeurs qualifiés en sécurité à valider des changements sur la branche principale.

Les mainteneurs bénévoles sont des héros, mais il faut (devrait) tout un village pour maintenir des logiciels sécurisés

Pour ceux qui ne sont pas du domaine de l'ingénierie logicielle, l'idée qu'une communauté passionnée de bénévoles maintienne minutieusement des systèmes critiques sur son temps libre est difficile à concevoir, mais c'est la nature du développement open source, et cela reste une zone de risque critique pour les professionnels de la sécurité protégeant la chaîne d'approvisionnement.

Le logiciel open source est une partie vitale de l'écosystème numérique de pratiquement chaque entreprise, et les mainteneurs de confiance (dont la plupart agissent de bonne foi) sont de véritables héros dans leur quête désintéressée de progrès technologique et d'intégrité, mais il est absurde de les laisser travailler en isolement. En ces temps centrés sur le DevSecOps, la sécurité est une responsabilité partagée, et chaque développeur doit être armé des connaissances et des outils adaptés pour naviguer dans les problèmes de sécurité qu'il est susceptible de rencontrer. La sensibilisation à la sécurité et les compétences pratiques doivent être non négociables dans le processus de développement logiciel, et il appartient aux leaders de la sécurité d'influencer le changement au niveau de l'entreprise.
‍

‍Construisez dès aujourd'hui une culture de sécurité florissante dans votre organisation avec les cours approfondis de Secure Code Warrior.