Xz/liblzma : explication de l’obfuscation de l’étape Bash

Explication de l’obfuscation de l’étape Bash

• Un backdoor a été découvert dans xz/liblzma. Il affecte les serveurs OpenSSH.
• Plutôt que le binaire contenant le backdoor, l’attention se porte sur la partie bash initiale et sur la méthode d’obfuscation simple mais ingénieuse qui a été utilisée.
• Cet article explique comment l’étape bash est obfusquée et extraite.

Avant de commencer

• Deux versions de xz/liblzma (5.6.0 et 5.6.1) sont concernées. Il existe de légères différences.
• La partie bash est divisée en trois étapes (ou quatre étapes ?) et chaque étape est nommée de Stage 0 à Stage 2.
• Il est aussi prévu de parler du « Stage 3 », mais il n’est peut-être pas encore totalement implémenté.
• Les étapes obfusquées/chiffrées ainsi que le backdoor binaire suivant sont cachés dans deux fichiers de test.

Stage 0

• Le point de départ est le fichier m4/build-to-host.m4. Ce code est exécuté à un moment du processus de build pour extraire le script Stage 1.
• Il lit des octets depuis un fichier de test et les envoie vers la sortie standard, puis utilise la commande tr pour mapper des caractères vers d’autres caractères.

Stage 1

• Un fichier bash commençant par « ####Hello#### ». Il est conçu pour ne s’exécuter que sous Linux.
• Il contient un eval pour extraire srcdir depuis config.status, ainsi qu’une chaîne complexe de commandes head qui saute certains octets avant de produire la sortie.
• Il applique un chiffrement par substitution simple avec la commande tr, puis décompresse avec la commande xz avant exécution.

Stage 2

• Stage 2 est le script bash qui modifie le véritable processus de compilation.
• Il semble exister un système d’« extensions/patchs », permettant d’exécuter de nouveaux scripts sans avoir à modifier en permanence les fichiers de test.
• Il contient du code qui extrait des fichiers .o et les intègre dans le processus de compilation/édition de liens.

Résumé

• Ce processus est extrêmement bien dissimulé et assemblé de manière complexe en n’utilisant que des outils standards en ligne de commande.
• Avec son exécution en 3 étapes et son système d’« extensions », il est conçu pour l’avenir afin d’éviter d’avoir à modifier de nouveau les fichiers de test binaires.
• Le fait qu’une telle attaque ait été découverte par hasard laisse de nombreuses questions ouvertes au sein de la communauté de la sécurité.

Avis de GN⁺

• Cet article souligne l’importance de la sécurité logicielle et des attaques sur la supply chain. Il rappelle qu’il faut être conscient des vulnérabilités pouvant apparaître dans le processus de build logiciel, ainsi que de l’importance de la revue de code et des audits de sécurité.
• Les techniques d’obfuscation et les méthodes d’attaque multi-étapes montrent à quel point les attaquants peuvent infiltrer un système de manière sophistiquée. Ces techniques ont aussi une valeur pédagogique pour les professionnels de la sécurité.
• Parmi les autres outils ou projets de sécurité offrant des fonctions similaires, on peut citer Dependency-Check d’OWASP ou la Nexus Platform de Sonatype. Ils aident à identifier les vulnérabilités de sécurité dans les dépendances logicielles.
• Lors de l’adoption de ce type de techniques, il faut renforcer la sécurité à toutes les étapes de la supply chain logicielle. Le bénéfice est une meilleure sûreté des systèmes, mais l’inconvénient est que si des attaquants utilisent de telles méthodes, leur détection peut devenir difficile.
• Cet incident met en lumière à la fois les forces et les faiblesses de la communauté open source. Les revues et contributions communautaires sont essentielles à la croissance et à la sécurité des projets, mais elles impliquent aussi un risque lié à d’éventuels contributeurs malveillants.