Porte dérobée dans XZ Utils : tout ce qu'il faut savoir et les actions possibles
Synthèse
CVE-2024-3094 est une vulnérabilité découverte dans la bibliothèque open source XZ Utils provenant d'un code malveillant qui a été poussé dans la bibliothèque par l'un de ses responsables.
Elle a été signalée à l'origine comme une porte dérobée de contournement d'authentification SSH, mais une analyse plus approfondie indique que cette porte dérobée active réellement l'exécution de code à distance (RCE).
L'acteur malveillant a commencé à contribuer au projet XZ il y a près de deux ans, construisant lentement sa crédibilité jusqu'à ce qu'on lui accorde des fonctions de responsable. Ces opérations à long terme relèvent généralement d'acteurs malveillants parrainés par l'État, mais il n'existe pas d'attribution spécifique à l'heure actuelle.
Étant donné que la porte dérobée affecte les dernières versions de XZ Utils, la procédure recommandée est de rétrograder vers une version non compromise. Dans cet article de blog, nous proposons d'autres atténuations potentielles pour limiter le rayon d'action de l'attaque.
Rétrospective
XZ Utils, et sa bibliothèque sous-jacente liblzma, sont des projets open source qui implémentent la compression et la décompression lzma. Ils sont inclus dans de nombreuses distributions Linux prêtes à l'emploi, sont très populaires auprès des développeurs et sont largement utilisés dans l'ensemble de l'écosystème Linux.
Il y a près de deux ans, un développeur du nom de Jia Tan a rejoint le projet et a commencé à ouvrir des requêtes pull pour effectuer diverses corrections de bugs ou améliorations. Jusqu'ici, rien d'anormal ; c'est ainsi que les choses fonctionnent dans le monde de l'open source. Finalement, après avoir acquis confiance et crédibilité, Jia Tan a commencé à obtenir des autorisations pour le référentiel ; d'abord, des autorisations de commit (proposition de modification du code) et, finalement, des droits de gestionnaire de versions.
Il semble que dans le cadre de ses efforts pour obtenir ces autorisations, Jia Tan a utilisé une forme intéressante de technique d'ingénierie : il a utilisé de faux comptes pour envoyer une myriade de requêtes de fonctionnalités et de plaintes concernant des bugs pour faire pression sur le responsable d'origine, ce qui a finalement entraîné la nécessité d'affecter un autre responsable au référentiel.
Après avoir contribué au code pendant environ deux ans, en 2023, Jia Tan a introduit quelques changements dans XZ qui ont été inclus dans la version 5.6.0. Parmi ces changements se trouvait une porte dérobée sophistiquée.
La porte dérobée
La porte dérobée est assez complexe. Pour commencer, vous ne la trouverez pas dans le référentiel xz GitHub (qui est actuellement désactivé, mais ce n'est pas le sujet). Dans ce qui semble être une tentative pour éviter la détection, au lieu de pousser des éléments de la porte dérobée vers le référentiel git public, le responsable malveillant ne l'a inclus que dans les versions tarball du code source. Certains éléments de la porte dérobée restaient donc relativement cachés, tout en étant toujours utilisés pendant le processus de compilation de projets dépendants.
La porte dérobée est composée de nombreux éléments introduits sur plusieurs commits :
Utilisation du mécanisme IFUNC dans le processus de compilation, qui sera utilisé par le logiciel malveillant pour détourner les fonctions symbol resolve
Intégration d'un objet partagé dissimulé dans les fichiers de test
Exécution d'un jeu de scripts pendant le processus de compilation de la bibliothèque qui extrait l'objet partagé (non inclus dans le référentiel, uniquement dans les versions, mais ajouté à .gitignore)
Désactivation du landlock, qui est une fonction de sécurité permettant de restreindre les privilèges de processus
La chaîne d'exécution comprend également de plusieurs étapes :
Le script malveillant build-to-host.m4 est exécuté pendant le processus de compilation de la bibliothèque et décode le fichier « test » bad-3-corrupt_lzma2.xz dans un script bash
Le script bash effectue alors un processus de décodage plus complexe sur un autre fichier « test », good-large_compressed.lzma, le décodant dans un autre script
Ce script extrait ensuite un objet partagé liblzma_la-crc64-fast.o, qui est ajouté au processus de compilation de liblzma
Ce processus est certes difficile à suivre. Nous vous recommandons l'infographiede Thomas Roccia pour une excellente référence visuelle et une analyse approfondie.
L'objet partagé lui-même est compilé dans liblzma, et remplace le processus de résolution de nom de fonction classique. Pendant le chargement du processus (n'importe lequel), les noms de fonction sont résolus en pointeurs réels vers la mémoire de processus, pointant vers le code binaire. La bibliothèque malveillante interfère avec le processus de résolution des fonctions, elle pourrait donc remplacer le pointeur de fonction de la fonctionnalité OpenSSH RSA_public_decrypt (Figure 1).
Elle pointe ensuite cette fonction vers une fonctionnalité malveillante qui lui est propre et qui, selon l'étude publiée par Filippo Valsorda, extrait une commande du certificat du client authentifiant (après avoir vérifié qu'il s'agit de l'acteur malveillant) et la transmet à la fonction system() pour exécution, réalisant ainsi l'exécution de RCE avant l'authentification.
Figure 1 : Le processus de hooking liblzma
Pour une explication plus détaillée des éléments de la porte dérobée, vous pouvez lire la publication d'Andres Freund sur openwall.
Impact potentiel
Actuellement, il semble que la porte dérobée soit ajoutée au démon SSH sur la machine vulnérable, permettant à un attaquant distant d'exécuter du code arbitraire. Cela signifie que toute machine disposant du package vulnérable qui expose SSH à Internet est potentiellement vulnérable.
Cette porte dérobée est presque devenue l'un des facilitateurs d'intrusion les plus importants jamais détecté ; jusqu'à en éclipser SolarWinds. Les attaquants ont presque pu accéder immédiatement à n'importe quelle machine Linux exécutant une distribution infectée, qui inclut Fedora, Ubuntu et Debian. Presque.
Une seule personne a empêché cela de se produire : Andres Freund. Après avoir étudié un problème de latence de 500 ms qui a été introduit après une mise à jour logicielle, Andres a pu retracer le problème jusqu'au package xz et finalement identifier la porte dérobée.
Cela soulève évidemment beaucoup de préoccupations. Nous avons eu de la chance. Si cette porte dérobée n'avait pas été détectée par un ingénieur curieux, combien de temps serait-elle restée active ?
Et peut-être encore plus préoccupant : et si cela s'était déjà produit auparavant ?
Détection et prévention
Gestion des versions
La procédure recommandée par l'Agence de cybersécurité et de sécurité des infrastructures (CISA) permet de rétrograder vers une version non compromise, telle que la version 5.4.6.
Pour savoir quelle version de XZ Utils ou liblzma est actuellement installée sur vos systèmes, vous pouvez exécuter la requête suivante dans Akamai Guardicore Segmentation Insight pour rechercher les instances chargées de la bibliothèque liblzma (Figure 2).
SELECT DISTINCT path AS liblzma_path
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%"
Figure 2 : Interrogation des instances chargées de liblzma
Vous pouvez également exécuter la requête suivante pour trouver le gestionnaire de packages pour la version installée.
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
Bien sûr, vous pouvez également filtrer pour afficher uniquement les actifs vulnérables.
SELECT path AS vulnerable_item, "Loaded Library" AS type, '5.6%' AS version
FROM process_memory_map
WHERE LOWER(path) LIKE "%liblzma%5.6%"
SELECT name AS vulnerable_item, 'DEB' AS type, version
FROM deb_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
UNION
SELECT name AS vulnerable_item, 'RPM' AS type, version
FROM rpm_packages
WHERE (LOWER(name) LIKE '%xz-utils%' OR LOWER(name) LIKE '%liblzma%')
AND version LIKE '5.6.%'
Recherche des menaces
Étant donné que la porte dérobée exécute en fait des commandes système, et ne permet pas seulement l'authentification, il pourrait être possible de détecter ce comportement via le suivi des processus.
Habituellement, lors de la connexion, un nouveau shell est créé pour l'utilisateur et exécute le processus shell par défaut (comme bash). Cependant, avec cette porte dérobée, la commande malveillante est en fait exécutée par le processus du démon SSH, sshd, ce qui pourrait déclencher une anomalie.
Notre service de recherche des menaces, Akamai Hunt, dispose de méthodes pour détecter de telles anomalies ; par exemple, en suivant constamment une occurrence de type d'activité de processus et ses processus enfants.
Kill switch
Selon certaines analyses réalisées sur la porte dérobée, il semble y avoir une kill switch (coupe-circuit) dans la variable d'environnement. L'ajout de la clé yolAbejyiejuvnup=Evjtgvsh5okmkAvj aux variables d'environnement du système peut désactiver la porte dérobée.
Références