Backdoor Linux: Social ingineering, GIT, xz/liblzma, sshd

Page principale

Répondre à ce message
Auteur: Olivier Allard-Jacquin
Date:  
À: Guilde Mailing list
Sujet: Backdoor Linux: Social ingineering, GIT, xz/liblzma, sshd
    Bonjour,

    une faille de sécurité est apparu sous Linux, rien de bien exceptionnel 
me direz-vous, si ce n'est qu'il s'agit d'un **sabotage volontaire** 
d'un développer, qui a patiemment planifié son coup sur une période de 
1.5 à 2 ans.


     En fait, il s'agit bien plus d'un backdoor / malware, que d'une 
simple faille de sécurité.


     Le programme impacté est "xz", un algorithme de compression de 
données, et liblzma, sa librairie qui lui est associée.


     La faille a été intégré par un développeur qui n'est pas le 
développeur originel de xz, et qui a simplement proposé de fournit son 
aide au projet, il y a 1.5 ans => Social ingineering


     Le but du sabotage n'est pas de pourrir la compression des données 
(en fait, les fichiers compressés et décompressés ne sont pas impactés). 
Il semblerait que le but soit d'impacter un autre logiciel (SSHd) qui 
peut être amené à l'utiliser, si il est lié à liblzma (linkage dynamique).


     SSHd n'est ni plus ni moins que LE logiciel de référence qui permet 
de se connecter à distance sur une machine.


     L'analyse est en cours, mais il semblerait que le but était 
d'accéder aux clés privées de SSH, ce qui est excessivement grave.


     Plus d'informations et de commentaires ici (Français)


https://linuxfr.org/news/xz-et-liblzma-faille-de-securite-volontairement-introduite-depuis-au-moins-deux-mois

https://linuxfr.org/users/ytterbium/journaux/xz-liblzma-compromis

     Et cette page (EN) qui résume tout le process :


https://boehs.org/node/everything-i-know-about-the-xz-backdoor

     La subtilité du truc, c'est que le code de la backdoor était placé 
dans un innocent fichier de test, appelé "bad-3-corrupt_lzma.xz", qui se 
faisait passé pour un fichier dédié au test du code de xz.


     La mécanique afin d'injecter le code malicieux est très subtile et 
indirecte, et note d'une volonté du développeur de bien planquer sa 
backdoor :


- un jour X, il a poussé dans le GIT le fichier de test
"bad-3-corrupt_lzma.xz". En fait, c'est un binaire linux compilé (ELF),
mais dont il a tripatouillé certains caractères et certains blocs de
données, afin que cela n'apparaissent pas comme de l'ELF. Notamment, les
premiers caractères du fichier de test n'ont pas le header d'un ELF,
mais d'un fichier compressé "xz" tout ce qu'il y a de standard. Donc si
l'on tente de le décompresser, cela va planter, comme son nom l'indique
"bad-3-corrupt_lzma.xz".

- le jour Y, il a poussé sur le GIT un 2nd fichier, (build-to-host.m4),
qui est exécuté par la chaîne de compilation, afin de compiler le
programme. Ce fichier *.m4 va avoir plusieurs instructions, dont le le
but final, avec l'aide de scripts bash eux-aussi lancés par la chaîne de
compilation, est de rajouter la backdoor aux programmes compilés. Et
notamment, à la librairie "liblzma*.o", qui peut-être linké à sshd, via
systemd (le mécanisme de boot des Linux, qui remplacé les scripts d'init).

- lorsqu'un utilisateur télécharge les fichiers de GIT, ou via un
.tar.gz , il récupère:

+ le code source "propre"

+ la backdoor qui n'est pas reconnu comme un ELF, mais comme un xz
corrompu. Disons que c'est une backdoor "démilitarisée"

+ toute la chaîne de compilation, qui va permet de "re-militariser" la
backdoor, et l'injecter dans le "liblzma*.o"

+ l'intérêt de faire cette manipulation via la chaîne de compilation,
c'est que c'est une étape obligé afin de re-générer le programme, et que
les utilisateurs vont plus se concentrer sur le code du programme,
plutôt que la chaîne de compilation

     Il y a un diagramme qui décrit tout le processus:
https://img.linuxfr.org/img/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f474a2d366d443961494141526169593f666f726d61743d6a7067266e616d653d39303078393030/GJ-6mD9aIAARaiY?format=jpg&name=900x900


     La faille a été découverte par un utilisateur qui n'a rien à voir 
avec le projet, et qui a simplement constaté que sa connexion ssh était 
plus lente de 0.5s, suite à une mise à jour de sa machine ... Chapeau à 
lui !!!


     La faille a impactée Debian Testing pendant 1 mois. Debian a 
immédiatement réagit en remettant une ancienne version de xz, qui date 
d'avant les modifications du développeur malicieux. La commande 
ci-dessous montre que la machine est corrigé:


$ dpkg -l|grep xz
ii xz-utils 5.6.1+really5.4.5-1 amd64 XZ-format compression utilities

     Le développeur (incriminé a poussé Ubuntu pour que son code soit 
intégré, probablement avant la prochaine LTS, mais heureusement cela n'a 
pas été fait.


     Fedora, Kali, OpenSUSE, ArchLinux sont aussi sur le coup.


    Cordialement,
                        Olivier
-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
        /   / \  / \   \   Web:  http://olivieraj.free.fr/
       /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!