Affaire de la backdoor XZ - premiers résultats de l’analyse

 (securelist.com)
2 points par GN⁺ 2024-04-13 | 1 commentaires | Partager sur WhatsApp

  • Chronologie des événements :

    • 2024.01.19 : le site web de XZ est déplacé vers GitHub Pages par un nouveau mainteneur (jiaT75)
    • 2024.02.15 : build-to-host.m4 est ajouté à .gitignore
    • 2024.02.23 : deux « fichiers de test » contenant des étapes de script malveillant sont introduits
    • 2024.02.24 : sortie de XZ 5.6.0
    • 2024.02.26 : commit dans CMakeLists.txt sabotant la fonctionnalité de sécurité Landlock
    • 2024.03.04 : la backdoor provoque des problèmes avec Valgrind
    • 2024.03.09 : les deux « fichiers de test » sont mis à jour, les fonctions CRC sont modifiées, le problème Valgrind est « corrigé »
    • 2024.03.09 : sortie de XZ 5.6.1
    • 2024.03.28 : le bug est découvert, Debian et RedHat sont notifiés, Debian annule XZ
    • 2024.03.29 : publication d’un email sur la mailing list OSS-security, RedHat confirme avoir livré une version backdoorée de XZ
    • 2024.03.30 : Debian arrête les builds et lance le processus de reconstruction
    • 2024.04.02 : le développeur principal de XZ reconnaît l’incident de backdoor

  • Valeurs de hachage des distributions XZ contenant la backdoor malveillante :

    • xz-5.6.0 : hachages MD5, SHA1 et SHA256 fournis
    • xz-5.6.1 : hachages MD5, SHA1 et SHA256 fournis

Analyse initiale de l’infection

  • Stage 1 - script build-to-host altéré :

    • Les fichiers source de la release étaient initialement inoffensifs, mais le fichier build-to-host.m4, qui exécute du code malveillant lorsqu’il est téléchargé depuis une URL contrôlée par le hacker, y était inclus
    • Ce fichier .m4 est exécuté pendant le build et modifie puis décompresse le premier fichier ajouté au dossier de test

  • Stage 2 - script shell injecté :

    • Le script malveillant injecté par le fichier .m4 vérifie s’il s’exécute dans le processus de build visé sous Linux
    • Il utilise le fichier good-large_compressed.lzma pour exécuter l’étape suivante ; ce fichier est compressé normalement, mais les données décompressées contiennent des données parasites
    • Il extrait 33 492 octets avec les commandes head/tail, puis applique une substitution de base avec la commande tr pour lever l’obfuscation

  • Stage 3 - extraction de la backdoor :

    • Le script shell de la dernière étape effectue plusieurs vérifications pour confirmer qu’il s’exécute dans l’environnement attendu
    • Il extrait ensuite le code binaire de la backdoor lui-même, caché à un autre offset dans le même fichier good-large_compressed.lzma
    • Il extrait le fichier avec l’outil XZ et déchiffre les données binaires au moyen d’une série d’appels à head utilisant un algorithme proche de RC4
    • Il extrait le fichier compressé avec XZ, supprime les octets du début à partir d’une valeur prédéfinie, puis l’enregistre sous liblzma_la-crc64-fast.o
    • Il modifie la fonction is_arch_extension_supported de crc_x86_clmul.h pour remplacer l’appel à __get_cpuid par _get_cpuid

Analyse de la backdoor binaire

  • Scénario de chargement furtif :

    • XZ utilise les fonctions lzma_crc32 et lzma_crc64 pour le calcul CRC, stockées dans la table des symboles ELF avec le type IFUNC
    • IFUNC est utilisé pour décider dynamiquement s’il faut employer une version optimisée
    • La backdoor est stockée sous forme de fichier objet, et son objectif principal est d’être liée au binaire principal lors de la compilation
    • Le fichier objet contient le symbole _get_cpuid ; en supprimant un underscore du code source d’origine, lorsque le code appelle _get_cpuid, c’est en réalité la version de la backdoor qui est appelée

  • Analyse du code de la backdoor :

    • Le code initial de la backdoor est appelé deux fois, et l’activité réellement malveillante commence lorsque l’IFUNC lzma_crc64 appelle _get_cpuid
    • Il recherche l’adresse GOT afin de localiser le pointeur cpuid, puis le remplace par un pointeur vers la fonction malveillante principale
    • L’objectif principal est de hooker certaines fonctions pour pouvoir surveiller toutes les connexions vers les systèmes infectés

  • Comportements clés :

    • Les fonctions libcrypto telles que RSA_public_decrypt, EVP_PKEY_set1_RSA et RSA_get0_key sont visées pour le hooking
    • Il vérifie si le processus courant répond aux critères d’exécution et confirme la présence d’un kill switch
    • Il effectue des opérations sur les chaînes à l’aide d’une structure Trie
    • Il utilise plus de trois routines de résolution de symboles pour localiser les structures ELF Symbol
    • Il parvient au hooking de fonctions en détournant les routines de résolution de symboles via un abus de la fonctionnalité rtdl-audit

L’avis de GN⁺

  • Cet article montre très bien un cas d’attaque extrêmement sophistiqué dans lequel un malware a été injecté dans un logiciel open source. Il rappelle que les avantages de l’open source peuvent aussi être exploités à mauvais escient.

  • Les cyberattaques et backdoors visant les systèmes Linux deviennent de plus en plus sophistiquées. En particulier, les attaques via des serveurs SSH peuvent constituer une menace de sécurité majeure.

  • D’un autre côté, cela montre aussi la capacité d’autorégulation de l’écosystème open source. La backdoor a finalement été découverte par la communauté, qui a réagi rapidement. La transparence est essentielle.

  • L’usage de techniques comme une structure de données Trie avancée, un Symbol Resolver et le hooking via dl_audit illustre l’évolution technique des malwares Linux. La sécurité des systèmes Linux exige elle aussi une vigilance particulière.

  • Lorsqu’une entreprise adopte un logiciel open source, il est indispensable de vérifier non seulement la licence, mais aussi les aspects de sécurité. Il faut absolument examiner si la source de distribution est digne de confiance et si le code fait l’objet d’une surveillance continue.

À lire aussi

1 commentaires

 
GN⁺ 2024-04-13
Avis sur Hacker News

Résumé :

  • Étant donné l’ampleur des efforts déployés par l’attaquant dans les scripts et le code pour échapper à la détection, l’ensemble de ce projet peut servir d’alternative à une transition ou à plusieurs efforts menés en parallèle
  • Il faut garder à l’esprit que se focaliser sur SSHD peut avoir des répercussions sur d’autres parties du système dans son ensemble, ainsi que sur des aspects techniques et sociaux
  • Il pourrait s’agir d’une mesure de durcissement utile que chaque bibliothèque liée dynamiquement dispose de sa propre GOT et que, une fois l’édition de liens dynamique terminée, la table soit marquée en lecture seule
  • Le code source semble avoir été généré en exécutant un désassembleur, en comprenant ce que fait le code, puis en renommant tous les éléments avec des noms descriptifs
  • Le ralentissement et la latence de SSH causés par un bug de la porte dérobée ont finalement conduit à sa découverte, et l’on se demande si une analyse a été menée à ce sujet
  • Le dépôt xz est réapparu sur GitHub, et les mainteneurs sont en train de faire du ménage, notamment en validant des modifications supprimant la prise en charge de ifunc et du code générant les fichiers de test
  • On imagine qu’il existe beaucoup de portes dérobées que personne n’a découvertes, tout en espérant qu’il n’y en ait aucune d’aussi discrète que celle-ci