CVE-2024-3094 — Backdoor dans XZ Utils

Uniquement à des fins éducatives et de recherche en sécurité autorisée.

Description de la vulnérabilité

CVE-2024-3094 est une backdoor introduite dans les versions 5.6.0 et 5.6.1 de XZ Utils (liblzma), découverte le 29 mars 2024 par le chercheur en sécurité Andres Freund. Elle a reçu un score CVSS de 10.0 (Critique).

Il s'agit d'une attaque de la chaîne d'approvisionnement menée pendant plus de deux ans par un acteur menaçant connu sous le nom de « Jia Tan » (JiaT75), qui a gagné la confiance au sein du projet jusqu'à obtenir le statut de co-mainteneur et a introduit la backdoor directement dans les tarballs de distribution.

Mécanisme technique

La backdoor fonctionne comme suit :

1. La liblzma.so malveillante intercepte la fonction RSA_public_decrypt() dans OpenSSH via le mécanisme IFUNC de glibc, en interférant avec le processus d'authentification SSH.
2. Lorsqu'un client se connecte, la backdoor évalue un champ spécifique dans le certificat SSH présenté.
3. Si ce champ contient une charge utile chiffrée avec ChaCha20 et signée avec une clé privée Ed448 spécifique, la backdoor exécute la commande intégrée via system() avec les privilèges de sshd (root).
4. Si la signature est invalide, sshd poursuit son déroulement normal sans aucune anomalie.

Conditions d'exploitation

• Système avec glibc (support IFUNC)
• XZ Utils 5.6.0 ou 5.6.1 installé
• sshd lancé depuis systemd (condition critique — l'interception IFUNC ne s'active pas si sshd est lancé manuellement en ligne de commande)
• Système x86-64

Distributions initialement affectées

• Fedora Linux 40 beta / Rawhide
• Debian unstable, testing, experimental
• Kali Linux
• Arch Linux (images entre 2024-02-24 et 2024-03-28)

Environnement de laboratoire

Ce laboratoire reproduit le mécanisme de la backdoor en utilisant des clés Ed448 personnalisées au lieu des clés de l'acteur d'origine (qui n'ont jamais été rendues publiques).

Pourquoi nous utilisons chroot

Dans les systèmes réellement affectés, il n'y avait pas de chroot. La backdoor opérait directement sur le sshd du système, qui chargeait la liblzma.so malveillante comme n'importe quelle autre bibliothèque partagée — de manière totalement transparente pour le système et ses administrateurs.

Dans ce laboratoire, nous utilisons chroot uniquement pour une raison pratique : nous devons exécuter un sshd avec une version spécifique de liblzma.so sans remplacer les bibliothèques du système hôte. C'est un choix de conception pour l'environnement de recherche, et non le reflet du fonctionnement de la backdoor en production.

Composants

Pile cible

• Ubuntu 22.04.1 LTS AMD64
• glibc 2.35
• OpenSSH 8.9p1
• systemd 249
• liblzma 5.6.1 (patchée)

Modifications apportées pour cette cible

La backdoor d'origine nécessite des conditions très spécifiques qui n'existent pas automatiquement dans un environnement de laboratoire. Les modifications suivantes ont été nécessaires :

1. Remplacement de liblzma.so

La liblzma.so.5 incluse dans le dépôt d'origine de MagpieRYL utilise une clé Ed448 inconnue qui est incompatible avec le binaire xzbot inclus. La liblzma.so.5.6.1 originale et authentique a été téléchargée depuis le snapshot Debian (sha256 vérifié) et patchée à l'aide de patch.py de amlweems/xzbot avec seed=0 :

original sha256:  605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4
patched sha256:   ea7206ab4b0c3479ff1b478c8803adc9e7aeba243254a9f601b626ef8aa80e3d
patched offset:   0x24470

La clé publique Ed448 de l'acteur d'origine a été remplacée par :

5b 3a fe 03 87 8a 49 b2 82 32 d4 f1 a4 42 ae bd
e1 09 f8 07 ac ef 7d fd 9a 7f 65 b9 62 fe 52 d6
54 73 12 ca ce cf f0 43 37 50 8f 9d 25 29 a8 f1
66 91 69 b2 1c 32 c4 80 00

2. Type=simple dans le service systemd

Le service d'origine utilise Type=notify, ce qui exige que sshd envoie une notification de démarrage à systemd. Le sshd dans le chroot ne l'envoie pas, ce qui provoque des délais d'attente. Modifié en Type=simple.

3. Répertoires chroot éphémères

sshd nécessite /run/sshd pour la séparation des privilèges. Ce répertoire n'existe pas dans le chroot et est effacé à chaque redémarrage car run/ est un tmpfs. Résolu avec un ExecStartPre qui le régénère automatiquement avant chaque démarrage du service.

Utilisation

Exploitation depuis la même machine

./xzbot -addr 127.0.0.1:2024 -cmd 'echo pwned > /tmp/result'
cat /home/user/CVE-2024-3094-backdoor-env-container/env_fs/tmp/result

Exploitation depuis une autre machine

./xzbot -addr <TARGET_IP>:2024 -cmd 'echo pwned > /tmp/result'

Emplacement des fichiers générés par l'exploit

La commande s'exécute dans le chroot, donc tout fichier créé sous /tmp/ dans le contexte de la backdoor est stocké à :

/home/user/CVE-2024-3094-backdoor-env-container/env_fs/tmp/

C'est-à-dire que si la commande est echo pwned > /tmp/result, le fichier se trouvera à :

/home/user/CVE-2024-3094-backdoor-env-container/env_fs/tmp/result

Pour localiser tout fichier généré par l'exploit :

find /home/user/CVE-2024-3094-backdoor-env-container/env_fs/tmp/ -type f

Note sur handshake failed: EOF

Le message ssh: handshake failed: EOF est le comportement attendu et correct. La backdoor exécute la commande et ferme la connexion sans établir de session SSH. Il n'indique pas un échec.

Important

Ce laboratoire utilise une paire de clés cryptographiques personnalisée (seed=0). La liblzma.so patchée n'accepte que les charges utiles signées avec la clé privée correspondante, c'est-à-dire celle utilisée par le xzbot compilé dans cet environnement. Tout autre client recevra EOF sans exécution.

Références

• Divulgation originale d'Openwall
• amlweems/xzbot
• MagpieRYL/CVE-2024-3094-backdoor-env-container
• Article de Datadog Security Labs
• Wikipédia — Backdoor XZ Utils

Avertissement

Cet outil est fourni uniquement à des fins éducatives et pour des tests de sécurité autorisés. Toute utilisation non autorisée contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite explicite de tester est illégale. L'auteur n'est pas responsable de toute mauvaise utilisation.