Discussion :

[Sandra Coret]

Découverte de Symbiote, un malware Linux extrêmement dangereux et "presque impossible à détecter", il existe depuis au moins novembre 2021 et semble avoir été développé pour cibler le secteur financier

Les adeptes des systèmes d'exploitation basés sur Linux invoquent souvent une plus grande sécurité pour justifier leur amour de la distro qu'ils ont choisie.

Si les distros Linux ont un meilleur bilan de sécurité que les systèmes Windows 11 et macOS parce qu'elles sont intrinsèquement plus sûres ou parce qu'elles ne sont tout simplement pas autant ciblées, le débat est ouvert, mais Linux n'en reste pas moins faillible.

Le malware Symbiote, découvert par des chercheurs en sécurité de BlackBerry et d'Intezer Labs, en est la preuve. Symbiote est inquiétant pour un certain nombre de raisons, notamment parce qu'il est décrit comme "presque impossible à détecter". Il s'agit également d'un malware extrêmement dangereux qui "parasite" les systèmes, infectant tous les processus en cours d'exécution et offrant aux acteurs de la menace des fonctionnalités de rootkit, un accès à distance, etc.

Symbiote est appelé ainsi en raison de la nature des attaques, le terme "symbiote" étant un terme biologique désignant un organisme qui vit en symbiose avec un autre organisme, parfois de manière parasitaire. Les chercheurs en sécurité affirment que Symbiote existe depuis au moins novembre 2021 et semble avoir été développé pour cibler le secteur financier.

Dans leur rapport, les chercheurs décrivent le malware comme suit :

"Ce qui différencie Symbiote des autres malwares Linux que nous rencontrons habituellement, c'est qu'il a besoin d'infecter d'autres processus en cours d'exécution pour infliger des dommages aux machines infectées. Au lieu d'être un fichier exécutable autonome qui est exécuté pour infecter une machine, il s'agit d'une bibliothèque d'objets partagés (SO) qui est chargée dans tous les processus en cours d'exécution à l'aide de LD_PRELOAD (T1574.006) et qui infecte la machine de manière parasite. Une fois qu'il a infecté tous les processus en cours d'exécution, il fournit à l'acteur de la menace une fonctionnalité de rootkit, la possibilité de récolter des informations d'identification et une capacité d'accès à distance."

Ils expliquent ensuite pourquoi le symbiote est si difficile à détecter :

Une fois que le logiciel malveillant a infecté une machine, il se cache, ainsi que tout autre logiciel malveillant utilisé par l'acteur de la menace, ce qui rend les infections très difficiles à détecter. Il est possible qu'une analyse médico-légale en direct d'une machine infectée ne révèle rien, car tous les fichiers, processus et artefacts réseau sont cachés par le malware. En plus de la capacité de rootkit, le malware fournit une porte dérobée permettant à l'acteur de la menace de se connecter en tant que n'importe quel utilisateur sur la machine avec un mot de passe codé en dur, et d'exécuter des commandes avec les privilèges les plus élevés.

Étant donné qu'il est extrêmement évasif, une infection par Symbiote est susceptible de " passer sous le radar ". Dans le cadre de nos recherches, nous n'avons pas trouvé suffisamment de preuves pour déterminer si Symbiote est utilisé dans des attaques très ciblées ou de grande envergure.

Un aspect technique intéressant de Symbiote est sa fonctionnalité de crochetage du Berkeley Packet Filter (BPF). Symbiote n'est pas le premier malware Linux à utiliser BPF. Par exemple, une porte dérobée avancée attribuée au groupe Equation a utilisé le BPF pour des communications secrètes. Cependant, Symbiote utilise le BPF pour dissimuler le trafic réseau malveillant sur une machine infectée.

Lorsqu'un administrateur lance un outil de capture de paquets sur la machine infectée, le bytecode BPF est injecté dans le noyau qui définit les paquets à capturer. Dans ce processus, Symbiote ajoute son bytecode en premier afin de pouvoir filtrer le trafic réseau qu'il ne veut pas que le logiciel de capture de paquets voie.

Symbiote est également capable de dissimuler son activité réseau à l'aide de diverses techniques. Cette couverture est parfaite pour permettre au logiciel malveillant de récolter des informations d'identification et de fournir un accès à distance à l'acteur de la menace.

Sources : Blackberry, Intezer

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Le nombre d'infections par des logiciels malveillants ciblant les appareils Linux a augmenté de 35 % en 2021, XorDDoS, Mirai et Mozi étaient les plus répandues, représentant 22 % des attaques

Des chercheurs en sécurité ont découvert CronRAT, un nouveau cheval de Troie d'accès à distance (RAT) furtif conçu pour attaquer les systèmes Linux, se cachant sous la forme d'une tâche planifiée

Les logiciels malveillants ciblant les systèmes d'exploitation basés sur Linux augmentent à la fois en volume et en complexité, dans un contexte d'évolution rapide du paysage des menaces

Le ransomware "Hive" chiffre désormais les systèmes Linux et FreeBSD, mais cette variante du ransomware est encore boguée et ne fonctionne pas toujours

[LittleWhite]

Bonjour,

Du coup, est-ce que c'est un fichier .so ? Quelle est la méthode d'infection ? Comment cela infecte les processus ?
Du coup, je me réponds (après avoir lu le rapport). Oui, c'est bien un fichier .so. Par contre, je n'ai pas compris comment il était amené à être chargé par le système. Une fois chargé, la bibliothèque met en place des mesures pour ne pas être détectée et pour être chargée par tout les processus lancés.

[gabriel21]

Les fichiers SO sont l'équivalent des DLL sous Linux.
Comme toi, je n'ai pas vu comment le système est corrompu.
Ni s'il est nécessaire que le programme utilisant la librairie soient en mode administrateur ou pas?

Cette étude ressemble a un placement de produit par Intezer, puisque, a en croire le rapport, l'infection ne peut être détecté que via un autre équipement et non pas par les outils habituel d'administration.

[Escapetiger]

Du coup, est-ce que c'est un fichier .so ? Quelle est la méthode d'infection ? Comment cela infecte les processus ?
Du coup, je me réponds (après avoir lu le rapport). Oui, c'est bien un fichier .so. Par contre, je n'ai pas compris comment il était amené à être chargé par le système. Une fois chargé, la bibliothèque met en place des mesures pour ne pas être détectée et pour être chargée par tout les processus lancés.

Une possibilité théorique peut être à partir d'un poste client Linux de type BYOD (Bring your own device) au sein de l'entreprise en ayant téléchargé une application incluant la bibliothèque .so

Les capacités réseau de Symbiote et sa furtivité faisant le reste :

• «Une fois qu'il a infecté tous les processus en cours d'exécution, il fournit à l'acteur de la menace une fonctionnalité de rootkit, la possibilité de récolter des informations d'identification et une capacité d'accès à distance»
• «Une fois que le logiciel malveillant a infecté une machine, il se cache, ainsi que tout autre logiciel malveillant utilisé par l'acteur de la menace, ce qui rend les infections très difficiles à détecter»

[sergio_is_back]

Bonjour,

Du coup, est-ce que c'est un fichier .so ? Quelle est la méthode d'infection ? Comment cela infecte les processus ?
Du coup, je me réponds (après avoir lu le rapport). Oui, c'est bien un fichier .so. Par contre, je n'ai pas compris comment il était amené à être chargé par le système. Une fois chargé, la bibliothèque met en place des mesures pour ne pas être détectée et pour être chargée par tout les processus lancés.

C'est vrai qu'il manque l'explication concernant le vecteur d'entrée du malware en question...
Après c'est pas la première fois qu'un malware a recours à une bibliothèque dynamique (en se faisant passer pour une bibliothèque légitime du système)

[disedorgue]

De plus, c'est un peu le principe des rootkit: "Faire passer des vessies pour des lanternes".

Si on dit qu'il ne faut surtout rien lancer en root, ce n'est pas pour rien.

Et c'est justement là le problème avec les divers manager de packet linux (apt,rpm,...) on doit être root pour les lancer et vu le bordel des dépots (non officiels) pour certaines applications, il suffit d'infecter un de ces dépots et la, c'est gagné.

[CaptainDangeax]

Oui comme toujours c'est bien gentil, cette fois ce n'est pas un exécutable mais une librairie .so
Sauf qu'une librairie .so il faut pouvoir l'installer, donc élévation des droits root.
Quant à dire que c'est indétectable, je reste également dubitatif. J'avais écris un script sur un sujet docker, génération de la signature sha1 de chaque fichier dans /usr et /lib, pour localiser lequel était altérée par rapport au serveur d'origine que je voulais dockeriser. J'ai trouvé et réussi mon projet docker. Ce type de détection est très facile à mettre en place pour un administrateur Linux un tant soit peu dégourdi
De même, on n'installe pas n'importe quoi depuis un dépôt non officiel et on n'exécute rien en root, c'est la base...
C'est toujours la même chose, oui avec les droits root c'est possible de tout péter sur une machine Linux, y compris rm -rf /* mais le soucis c'est d'acquérir ces fameux droits root

[JPLAROCHE]

il est dit INDETECABLE (et non pas comme dans le titre), utilise le root !!!!, malware ce charge sans que l'on s'en rendre compte, beaucoup de chose dans un petit bout de code entre autre bycode , il est aussi dit avec des user et mot passe en dure !!!! . bref il est passé au travers de firewall, de proxy, ÇA FAIT BEAUCOUP DE CHOSE À AVALER.
MAIS LE DÉNIGREMENT de Linux au travers de discours de ce genre ... il y a des règles de sécurité. Après si on enlève ses règles alors Linux devient win...

[marsupial]

Bonjour,

...Quelle est la méthode d'infection ? Comment cela infecte les processus ?...

Comme il s'agit d'un malware tout nouveau tout beau, personne ne le sait encore. source Ziff Davis

[argv225]

13/06/2022, 10h21
CaptainDangeax
Quant à dire que c'est indétectable, je reste également dubitatif. J'avais écris un script sur un sujet docker, génération de la signature sha1 de chaque fichier dans /usr et /lib, pour localiser lequel était altérée par rapport au serveur d'origine que je voulais dockeriser.

Le virus ne change pas les fichiers. Il ajoute une lib qui est chargée avant tout et cette librairie va intercepter les appels système. Cela veut dire que la signature SHA1 ne change pas et, surement, quand on fait un 'ls' ou 'find' ou autre commande pour trouver la lib elle même, le résultat est filtré, le fichier .so est caché.
La solution serait de démarrer sur un LiveCD et chercher le malware de cette façon, mais bon, il faut savoir ce qu'on cherche.

[Zéolith]

"Lorsqu'un administrateur lance un outil de capture de paquets sur la machine infectée,"

Bonjour,

Question d'un béotien: Dans un contexte d'analyse de sécurité, j'aurais tendance à être parano et vouloir faire une analyse de l'extérieur de la machine, par exemple, entre la machine et un switch ou un serveur. C'est idiot ? Impossible ?

Merci.

[disedorgue]

Tout dépend de comment tu veux faire cette analyse, ici il faut juste que l'on ne sollicite pas tout ce qui est software du dit os infecté.

Sinon, en bons outils d'analyse, si ceux-ci sont compilés avec des librairies statiques et non dynamique et (soit avant l'infection, soit depuis un système saint), on devrait pouvoir détecter le problème.
Il faut juste pouvoir analyser sans utiliser la lib en question (de quelque soit la manière).

Ce qui peut être très difficile, si le noyau l'utilise aussi (ce qui en principe, n'est pas le cas).

[Sve@r]

Bonjour

et, surement, quand on fait un 'ls' ou 'find' ou autre commande pour trouver la lib elle même, le résultat est filtré, le fichier .so est caché.

Pas mal ce virus magique. Il réussit à traficoter et "find" et "ls". Et "vi" aussi (avec "vi" on peut lire le contenu d'un dossier). Ah et pour qu'il soit parfait il faut aussi trafiquer "du" sinon on peut se poser des questions (comment? mon répertoire est plus gros que la taille des fichiers qu'il contient?) et aussi "df" (comment? mon fs est plus gros que la taille des fichiers et dossiers qu'il contient?). Et essayons d'oublier les outils C tels que opendir() et readdir()...
Pas évident évident de se cacher sous Linux...

Question d'un béotien: Dans un contexte d'analyse de sécurité, j'aurais tendance à être parano et vouloir faire une analyse de l'extérieur de la machine, par exemple, entre la machine et un switch ou un serveur. C'est idiot ? Impossible ?

Ce n'est pas idiot mais pas non plus possible. On ne peut pas travailler "de l'extérieur" de la machine. On est obligé d'y entrer pour pouvoir y travailler. Et quand on y est, on utilise alors les outils de la machine pour l'analyser donc si l'outil est failli, l'analyse l'est aussi.

Ce que tu peux faire de possible c'est démarrer ta machine depuis un "liveCD". L'OS est alors chargé depuis le CD et non plus depuis les disques durs. Et là tu peux alors lancer l'analyse des fichiers du disque depuis un OS sain. Toutefois il faut savoir ce que l'on cherche (tu ne me chercherais pas si tu ne m'avais pas déjà trouvé, Pascal). On peut tenter des solutions "hasardeuses" comme regarder les dates de modifs des dossiers et fichiers systèmes mais perso je suis partisan d'une solution plus radicale (et paradoxalement plus simple) : un doute sur mon OS alors je réinstalle l'OS. Avec un OS bien foutu au départ, avec un "/home" sur un autre FS ça se fait sans souci et sans perte pour les users.

Maintenant en ce qui concerne l'annonce d'intezer, elle est rempli de termes "pseudo professionnels" ronflants mais qui en réalité ne veulent rien dire quand on les met bout à bout

• le truc infecte des process en cours d'exécution => impossible, un process lancé par un userX (exemple root) n'est pas modifiable par un userY (exemple "non root"). Déjà que pour communiquer avec ses propres process même s'ils ont été programmés pour c'est déjà la galère...
• le truc infecte le process via une librairie .so parasite => ok donc c'est quand un process se lance qu'il charge la librarie. Mais personne ne dit comment la librairie a été installée. Ok certains parlent de dépots corrompus je veux bien admettre (mais ça repousse le problème à "comment ont-ils été corromus?"). Et là encore une RAZ reste ce qu'il y a de plus efficace. Si l'admin n'est pas trop manche, il a copié les fichiers importants dans /home/root (oui, chez-moi /root est un lien symbolique sur /home/root et comme /home a son propre FS...) lors de la première install et il peut remonter son OS assez rapidement. Perso, sous /home/root, j'ai un mini-clone de "/etc" qui contient tous mes fichiers de config. Une fois l'OS réinstallé, plus qu'à les recopier dans le vrai "/etc".

Bon bref, encore une annonce d'intezer faite pour foutre la pétoche à ceux qui ne connaissent pas Linux. La version plus évoluée du très bête "attention un tout nouveau virus super méchant va sortir, prévenez vite tous vos contacts". Evidemment que si on fait n'importe quoi avec root on peut foutre en l'air un Linux, tout le monde (ie tous les linuxiens) le savent. De même un avion c'est super sécurisé mais si le pilote fout le manche à piquer il le fout en l'air (enfin là c'est par terre) de la même façon. Linux est sécurisé mais un outil ne sera jamais plus sécurisé que celui qui l'administre. Evidemment si ce dernier est un branque... (remarquez j'ai vu des élèves admins qui me disaient "pour pas avoir de problème suffit de tout mettre en 777" )

[tabouret]

"Lorsqu'un administrateur lance un outil de capture de paquets sur la machine infectée,"

Bonjour,

Question d'un béotien: Dans un contexte d'analyse de sécurité, j'aurais tendance à être parano et vouloir faire une analyse de l'extérieur de la machine, par exemple, entre la machine et un switch ou un serveur. C'est idiot ? Impossible ?

Merci.

Ça s'appelle un IDS/IPS ^^

[heinquoi]

Un analyse qui me semble crédible
https://cybergeeks.tech/how-to-analy...y-of-symbiote/
finalement pas si difficile a détecter, extrait:
INDICATORS OF COMPROMISE
C2 domain: px32.nss.atendimento-estilo[.]com
SHA256: 121157e0fcb728eb8a23b55457e89d45d76aa3b7d01d3d49105890a00662c924
Files created: /usr/include/linux/usb/usb.h