pour assurer sa persistance, le virus crée des fichiers là ou il peut ; il suffit donc d'aller les chercher avec la commande find ; voici ce que cela donne sur un répertoire de backup, basé sur rsnapshot:
cd /backup/system/daily.0
find . -type f | egrep '/bin/systemd/systemd-daemon|/usr/lib/systemd/systemd-daemon|/.dbus/sessions/session-dbus|/.gvfsd/.profile/gvfsd-helper'
les chemins à chercher doivent contenir:
- /bin/systemd/systemd-daemon
- /usr/lib/systemd/systemd-daemon
- [$HOME]/.dbus/sessions/session-dbus
- [$HOME]/.gvfsd/.profile/gvfsd-helper
Posté par Marc Quinton .
Évalué à 6.
Dernière modification le 02 mai 2021 à 08:12.
sur un système Linux en production, un mécanisme de lock est mis en place et on peut observer la présence de ces fichiers :
- /usr/lib32/.X11/X0-lock
- /bin/lib32/.X11/X0-lock
- $HOME/.X11/X0-lock
- $HOME/.X11/.X11-lock
on peut aussi obtenir la liste des locks avec cette commande : cat /proc/locks
J'ai regardé l'article rapidement, où il est décrit le fonctionnement du logiciel, mais je n'ai pas vu de description du vecteur d'infection. Le logiciel malveillant se fait passer pour systemd, mais ça ne veut pas dire que systemd est le fautif. Soit je n'ai pas bien compris, soit le titre du lien est faux.
Pareil, je pige pas trop: c'est un truc qu'on peut chopper ou c'est systemd lui-même qui est en cause?
De ma lecture de l'article, ce n'est pas systemd qui est en cause : dans la partie "persistence", ils indiquent qu'il se démarre comme service systemd (ou via un script d'init pour les autres init).
C'est simplement qu'ils ont nommé le virus "systemd-daemon", ce qui est malin pour tromper l'administrateur peu averti, qui n'y fera pas attention.
Du coup, il me semble qu'il faudrait corriger le titre du lien ci-dessus, qui me semble inexact.
C'est rare mais me suis permis d'éditer le titre pour qu'il soit plus le reflet de la réalité et qu'il ne sèmes pas de trouble, en effet. J'espère que Marc ne m'en voudra pas de cette édition.
Poser une question ou ne pas comprendre quelque chose n'implique pas que ce quelque chose pose problème ni qu'il doive être remis en question.
Dans mon cas, il s'est juste fait que je n'étais pas certain d'avoir bien pigé qui faisait quoi (sur un sujet où je ne pige à peu près rien, c'est pas vraiment étonnant) et que, dans le doute, j'ai préféré demander ;)
# lien en Français
Posté par Marc Quinton . Évalué à 8.
https://www.it-connect.fr/rotajakiro-cette-porte-derobee-sous-linux-passe-sous-les-radars-depuis-2018/
# détection
Posté par Marc Quinton . Évalué à 6.
pour assurer sa persistance, le virus crée des fichiers là ou il peut ; il suffit donc d'aller les chercher avec la commande find ; voici ce que cela donne sur un répertoire de backup, basé sur rsnapshot:
les chemins à chercher doivent contenir:
- /bin/systemd/systemd-daemon
- /usr/lib/systemd/systemd-daemon
- [$HOME]/.dbus/sessions/session-dbus
- [$HOME]/.gvfsd/.profile/gvfsd-helper
[^] # Re: détection
Posté par Marc Quinton . Évalué à 6. Dernière modification le 02 mai 2021 à 08:12.
sur un système Linux en production, un mécanisme de lock est mis en place et on peut observer la présence de ces fichiers :
- /usr/lib32/.X11/X0-lock
- /bin/lib32/.X11/X0-lock
- $HOME/.X11/X0-lock
- $HOME/.X11/.X11-lock
on peut aussi obtenir la liste des locks avec cette commande :
cat /proc/locks# Backdoor?
Posté par ted (site web personnel) . Évalué à 10.
J'ai regardé l'article rapidement, où il est décrit le fonctionnement du logiciel, mais je n'ai pas vu de description du vecteur d'infection. Le logiciel malveillant se fait passer pour systemd, mais ça ne veut pas dire que systemd est le fautif. Soit je n'ai pas bien compris, soit le titre du lien est faux.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Backdoor?
Posté par DavidB (site web personnel) . Évalué à 5.
Pareil, je pige pas trop: c'est un truc qu'on peut chopper ou c'est systemd lui-même qui est en cause?
[^] # Re: Backdoor?
Posté par Samuel (site web personnel) . Évalué à 10.
De ma lecture de l'article, ce n'est pas systemd qui est en cause : dans la partie "persistence", ils indiquent qu'il se démarre comme service systemd (ou via un script d'init pour les autres init).
C'est simplement qu'ils ont nommé le virus "systemd-daemon", ce qui est malin pour tromper l'administrateur peu averti, qui n'y fera pas attention.
Du coup, il me semble qu'il faudrait corriger le titre du lien ci-dessus, qui me semble inexact.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Backdoor?
Posté par bubar🦥 (Mastodon) . Évalué à 10.
C'est rare mais me suis permis d'éditer le titre pour qu'il soit plus le reflet de la réalité et qu'il ne sèmes pas de trouble, en effet. J'espère que Marc ne m'en voudra pas de cette édition.
[^] # Re: Backdoor?
Posté par Marc Quinton . Évalué à 7.
merci mon ami.
[^] # Re: Backdoor?
Posté par Anonyme . Évalué à -2.
Comme quoi, il faudrait imposer de ne pas éditorialiser les titres des liens. Ici, le titre original, en anglais, convient très bien.
[^] # Re: Backdoor?
Posté par tisaac (Mastodon) . Évalué à 8.
Et quand le titre original ne convient pas ?
Et quand cela permet de faire une référence, un lien avec d'autres informations par exemple des échanges récents sur LinuxFR ?
Et quand cela fait rire ?
Et … ?
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Backdoor?
Posté par DavidB (site web personnel) . Évalué à 3.
+1.
Poser une question ou ne pas comprendre quelque chose n'implique pas que ce quelque chose pose problème ni qu'il doive être remis en question.
Dans mon cas, il s'est juste fait que je n'étais pas certain d'avoir bien pigé qui faisait quoi (sur un sujet où je ne pige à peu près rien, c'est pas vraiment étonnant) et que, dans le doute, j'ai préféré demander ;)
[^] # Re: Backdoor?
Posté par DavidB (site web personnel) . Évalué à 4.
Merci ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.