Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

EvilGnome

guitbass

Bonjour,

Doit-on s inquiéter de cette découverte (virus) ?

Cordialement

Roschan

Non.

guitbass

Roschan a écritNon.

Voilà une réponse claire et nette mais est-elle fondée ?

Nuliel

Bonjour,

Après avoir lu https://thehackernews.com/2019/07/linux-gnome-spyware.html , je peux dire que:
- ce virus n'est pas discret (trace dans le crontab, c'est pas très discret)
- ce virus doit être installé volontairement (j'ai vu sur reddit que les droits d'admin sont nécessaires pour l'installer mais je ne trouve pas dans la source citée, de toute façon quel que soit le niveau de droits nécessaires faut pas installer n'importe quoi)

Tu peux voir ça comme un script malicieux, du moment que tu le lances pas il dérange pas.
Et puis le script publié alors qu'il est pas fini....

Roschan

D'où vient l'info : de journaux putassiers qui ne font même pas la différence entre Linux en général et le bureau GNOME Shell

Quelle est leur source : une entreprise d'analystes en sécurité qui ne dit pas où/comment ils ont trouvé le virus

Qu'est le virus : une extension GS même pas terminée, et donc pas publiée non plus

Quel est le mode de contamination : un script bash qui auto-extrait les fichiers du virus

Un utilisateur normal exécute-t-il à l'aveugle des scripts bash, de taille conséquente et dont le contenu est illisible, qu'il aura cherché parmi les dépôts de développement d'hackers russes ? Non. Donc pourquoi vouloir s’inquiéter ?

----

Concernant les droits d'admin, c'est probablement une supposition faite par un lecteur à partir de ce qui est dit vis-à-vis de crontab, la plupart des gens éditant les tâches programmées en tant qu'admin, mais l'utilisateur a aussi ses propres moyens de programmer des tâches via crontab et systemd sans avoir besoin des permissions root, cette supposition me semble donc fausse

guitbass

Naziel a écritBonjour,

Après avoir lu https://thehackernews.com/2019/07/linux-gnome-spyware.html , je peux dire que:
- ce virus n'est pas discret (trace dans le crontab, c'est pas très discret)
- ce virus doit être installé volontairement (j'ai vu sur reddit que les droits d'admin sont nécessaires pour l'installer mais je ne trouve pas dans la source citée, de toute façon quel que soit le niveau de droits nécessaires faut pas installer n'importe quoi)

Tu peux voir ça comme un script malicieux, du moment que tu le lances pas il dérange pas.
Et puis le script publié alors qu'il est pas fini....

il faut taper crontab -e en ligne de commande ?

Nuliel

crontab -e sert à éditer le crontab, c'est crontab -l pour lister les tâches cron de l'utilisateur qui lance la commande.

Roschan a écritConcernant les droits d'admin, c'est probablement une supposition faite par un lecteur à partir de ce qui est dit vis-à-vis de crontab, la plupart des gens éditant les tâches programmées en tant qu'admin, mais l'utilisateur a aussi ses propres moyens de programmer des tâches via cronta et systemd sans avoir besoin des permissions root, cette supposition me semble donc fausse

C'est bien ce qu'il me semblait

guitbass

Roschan a écritD'où vient l'info : de journaux putassiers qui ne font même pas la différence entre Linux en général et le bureau GNOME Shell

Quelle est leur source : une entreprise d'analystes en sécurité qui ne dit pas où/comment ils ont trouvé le virus

Qu'est le virus : une extension GS même pas terminée, et donc pas publiée non plus

Quel est le mode de contamination : un script bash qui auto-extrait les fichiers du virus

Un utilisateur normal exécute-t-il à l'aveugle des scripts bash, de taille conséquente et dont le contenu est illisible, qu'il aura cherché parmi les dépôts de développement d'hackers russes ? Non. Donc pourquoi vouloir s’inquiéter ?

----

Concernant les droits d'admin, c'est probablement une supposition faite par un lecteur à partir de ce qui est dit vis-à-vis de crontab, la plupart des gens éditant les tâches programmées en tant qu'admin, mais l'utilisateur a aussi ses propres moyens de programmer des tâches via crontab et systemd sans avoir besoin des permissions root, cette supposition me semble donc fausse

ok, merci pour ces explications

Roschan

Ceci dit, même si ça ne concerne pas monsieur tout-le-monde, il y a pas mal d'utilisateurs avec des pratiques médiocres (mais sûrs de leur compétence puisque sachant lancer un script depuis un terminal) qui risquent de se trouver contaminés e jour où ce truc sera terminé

guitbass

Naziel a écritcrontab -e sert à éditer le crontab, c'est crontab -l pour lister les tâches cron de l'utilisateur qui lance la commande.
Roschan a écritConcernant les droits d'admin, c'est probablement une supposition faite par un lecteur à partir de ce qui est dit vis-à-vis de crontab, la plupart des gens éditant les tâches programmées en tant qu'admin, mais l'utilisateur a aussi ses propres moyens de programmer des tâches via cronta et systemd sans avoir besoin des permissions root, cette supposition me semble donc fausse
C'est bien ce qu'il me semblait

j ai tapé crontab -l et il me met no crontab for root

cqfd93

Bonjour,

guitbass a écritj ai tapé crontab -l et il me met no crontab for root

Voilà ce que ça donne chez moi :

moi@aurore:~$ crontab -l
no crontab for moi
moi@aurore:~$

Alors ton retour montre que tu es connecté en root… En regardant tes autres discussions, on peut raisonnablement penser que ta machine n'est pas un serveur, alors qu'est-ce que tu y fais en root ???

Plutôt que de poser de multiples question sur d'éventuelles failles de sécurité, pose-toi plutôt la question de la faille assise sur ta chaise !

guitbass

cqfd93 a écritBonjour,

guitbass a écritj ai tapé crontab -l et il me met no crontab for root
Voilà ce que ça donne chez moi :
moi@aurore:~$ crontab -l
no crontab for moi
moi@aurore:~$ 
Alors ton retour montre que tu es connecté en root… En regardant tes autres discussions, on peut raisonnablement penser que ta machine n'est pas un serveur, alors qu'est-ce que tu y fais en root ???

Plutôt que de poser de multiples question sur d'éventuelles failles de sécurité, pose-toi plutôt la question de la faille assise sur ta chaise !

J ai simplement tapé : sudo crontab -l et mot de passe

Roschan

mais... ce virus n'a aucune raison d'avoir les permissions de root, puisque ce n'est pas son mode opératoire décrit par l'article, du coup pourquoi avoir mis "sudo" avant ta commande ? des sudo inutiles lancés au hasard sont une menace pour la sécurité bien plus grande que ce virus inachevé

guitbass

Roschan a écritmais... ce virus n'a aucune raison d'avoir les permissions de root, puisque ce n'est pas son mode opératoire décrit par l'article, du coup pourquoi avoir mis "sudo" avant ta commande ? des sudo inutiles lancés au hasard sont une menace pour la sécurité bien plus grande que ce virus inachevé

ok , mais si je fais un apt-get clean par exemple il ne s execute pas , je dois ecrire sudo avant

Nuliel

Oui, sudo est à réserver uniquement aux tâches d'administration. Moins on l'utilise, mieux le pc se porte! (par exemple cet après midi, c'est à cause d'un sudo de trop sur un autre fil que les packages pip sont en vrac, et je n'ai pas pu conseiller autre chose que la réinstallation)
crontab c'est un programme qui permet d'exécuter à intervalle régulier des commandes. Il y a donc un crontab pour root, pour ton utilisateur, pour tous les autres utilisateurs d'ailleurs (chacun a le sien). Le fait que le script ait besoin des droits root n'est pas sourcé et est sûrement faux.

Roschan

guitbass a écrit
Roschan a écritmais... ce virus n'a aucune raison d'avoir les permissions de root, puisque ce n'est pas son mode opératoire décrit par l'article, du coup pourquoi avoir mis "sudo" avant ta commande ? des sudo inutiles lancés au hasard sont une menace pour la sécurité bien plus grande que ce virus inachevé
ok , mais si je fais un apt-get clean par exemple il ne s execute pas , je dois ecrire sudo avant

Je n'arrive pas à suivre le raisonnement : quel est le lien entre crontab et apt ?

guitbass

Roschan a écrit
guitbass a écrit
Roschan a écritmais... ce virus n'a aucune raison d'avoir les permissions de root, puisque ce n'est pas son mode opératoire décrit par l'article, du coup pourquoi avoir mis "sudo" avant ta commande ? des sudo inutiles lancés au hasard sont une menace pour la sécurité bien plus grande que ce virus inachevé
ok , mais si je fais un apt-get clean par exemple il ne s execute pas , je dois ecrire sudo avant
Je n'arrive pas à suivre le raisonnement : quel est le lien entre crontab et apt ?

aucun lien c est juste pour dire que pour executer certaines commandes il faut le sudo et c est pourquoi j'avais mis sudo devant crontab tout à l heure

Nuliel

Une chose très importante sur linux est la gestion des droits. Les utilisateurs peuvent utiliser l'ordi normalement (lire des mails, ...), l'administrateur gère l'installation des logiciels, les mises à jour... L'utilisateur a des droits restreints (s'il fait une grosse bêtise, au pire il détruit son compte, et perd ses données) alors que root a tous les droits (il peut donc en cas de grosse bêtise détruire la machine, rendre instable le système, ...). Sur linux, les utilisateurs et les administrateurs sont séparés.

sudo (subsitute user do) sert, le temps d'une commande, à avoir les mêmes droits que root (on peut demander à avoir les mêmes droits qu'un utilisateur en particulier, mais par défaut c'est l'utilisateur root). Il permet donc de passer des commandes avec tous les droits. Donc en cas de grosse bêtise, c'est le système entier qui peut être impacté. D'où l'intérêt de n'utiliser sudo que lorsque c'est vraiment obligatoire.
Par exemple, ici sudo devant crontab -l n'était pas utile car on s'intéresse au crontab de l'utilisateur et non de root.

Et sudo ne doit pas être vu comme un moyen de faire fonctionner une commande qui ne fonctionne pas à cause de "permission non accordée" mais comme une élévation de privilèges temporaire.

Par exemple, je traite depuis quelques jours un problème avec pip (c'est une sorte de apt-get pour python) qui a été utilisé avec sudo, les permissions sont cassées (dans le sens certaines choses qui devraient pas appartenir à root lui appartiennent) et du coup, la réparation était trop difficile/dangereuse.
C'est les mêmes conséquences lorsqu'on utilise sudo avec une application graphique ou lorsqu'on lance le serveur X avec sudo: le problème, c'est des droits qui sont changés, et qui ne sont plus adaptés.

Roschan

guitbass a écrit
Roschan a écrit
guitbass a écrit
ok , mais si je fais un apt-get clean par exemple il ne s execute pas , je dois ecrire sudo avant
Je n'arrive pas à suivre le raisonnement : quel est le lien entre crontab et apt ?
aucun lien c est juste pour dire que pour executer certaines commandes il faut le sudo et c est pourquoi j'avais mis sudo devant crontab tout à l heure

Aucun lien, du coup ce "c'est pourquoi" n'a pas de sens : il n'y a pas besoin de sudo pour exécuter crontab, donc tu n'avais aucune raison de mettre sudo, et c'est pourquoi on t'en fait la remarque. D'autant que le virus vise le crontab de l'utilisateur, et donc mettre sudo, en plus d'être un abus inutile des droits d'admin, est surtout la mauvaise manip à faire si ton but est de vérifier l'absence d'infection

Pending...

Je bosse de temps en temps sur un rootkit à titre expérimental et sur une plateforme de contrôle en php. Il fonctionne pas mal mais il n'a évidemment pas vocation à être publié (pour des raisons évidentes). J'y ajoute des fonctionnalités quand j'arrive à avancer sur des points que je ne connaissais pas.

Ce que j'ai pu découvrir, c'est que masquer sa présence dans crontab (en mode user), c'était faisable, même avec un simple script (cf. ma signature) si l'on n'utilise que "crontab -l". Je ne suis pas allé plus loin, c'était juste pour tester cette possibilité.

Tout ça pour dire qu'un malware sur Linux, ce n'est pas forcément compliqué à faire. On trouve même des keyloggers tout prêt avec code source sur le net. C'est juste qu'en dehors de l'expérimentation, ça ne sert pas à grand chose. Tout a déjà été dit au dessus, si on n'installe rien, pas même en mode user, on ne risque rien. C'est bien la limite d'un malware sur Linux : on peut pondre toutes les options qu'on veut dessus, si on n'arrive pas à le faire installer, ça ne vaut rien.

Page suivante »