web-dev-qa-db-fra.com

virus crond64 / tsm dans Ubuntu

Récemment, j'ai remarqué que mon serveur domestique devenait douloureusement lent. Toutes les ressources ont été consommées par deux processus: crond64 et tsm. Même si je les ai tués à plusieurs reprises, ils ont continué à apparaître encore et encore.

Dans le même temps, mon FAI m'informait d'un abus provenant de mon adresse IP:

==================== Excerpt from log for 178.22.105.xxx====================
Note: Local timezone is +0100 (CET)
Jan 28 20:55:44 shared06 sshd[26722]: Invalid user admin from 178.22.105.xxx
Jan 28 20:55:44 shared06 sshd[26722]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.22.105.xxx
Jan 28 20:55:45 shared06 sshd[26722]: Failed password for invalid user admin from 178.22.105.xxx port 33532 ssh2
Jan 28 20:55:46 shared06 sshd[26722]: Received disconnect from 178.22.105.xxx port 33532:11: Bye Bye [preauth]
Jan 28 20:55:46 shared06 sshd[26722]: Disconnected from 178.22.105.xxx port 33532 [preauth]
Jan 28 21:12:05 shared06 sshd[30920]: Invalid user odm from 178.22.105.xxx
Jan 28 21:12:05 shared06 sshd[30920]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.22.105.xxx
Jan 28 21:12:07 shared06 sshd[30920]: Failed password for invalid user odm from 178.22.105.xxx port 45114 ssh2
Jan 28 21:12:07 shared06 sshd[30920]: Received disconnect from 178.22.105.xxx port 45114:11: Bye Bye [preauth]
Jan 28 21:12:07 shared06 sshd[30920]: Disconnected from 178.22.105.xxx port 45114 [preauth]

J'ai été informé par ce site Web que je pourrais avoir un virus. J'exécute Sophos AV en analysant l'intégralité de mon disque dur et en effet, il a trouvé un virus dans /tmp/.mountfs/.rsync. J'ai donc supprimé le dossier entier et j'ai pensé que c'était tout. Mais il a continué à revenir après. J'ai ensuite vérifié le fichier cron de l'utilisateur dans /var/spool/cron/crontabs/Kodi (le virus fonctionnait en utilisant l'utilisateur de mon serveur multimédia Kodi), qui ressemblait à ceci:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (cron.d installed on Sun Feb  3 21:52:03 2019)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* */12 * * * /home/Kodi/.ttp/a/upd>/dev/null 2>&1
@reboot /home/Kodi/.ttp/a/upd>/dev/null 2>&1
5 8 * * 0 /home/Kodi/.ttp/b/sync>/dev/null 2>&1
@reboot /home/Kodi/.ttp/b/sync>/dev/null 2>&1
#5 1 * * * /tmp/.mountfs/.rsync/c/aptitude>/dev/null 2>&1

Il semble que le virus se réactive de temps en temps à partir d'un autre répertoire. Le contenu de ce répertoire est:

>>> ls /home/Kodi/.ttp/*
/home/Kodi/.ttp/cron.d  /home/Kodi/.ttp/dir2.dir

/home/Kodi/.ttp/a:
a  bash.pid  config.txt  crond32  crond64  cronda  crondb  dir.dir  pools.txt  run  stop  upd

/home/Kodi/.ttp/b:
a  dir.dir  rsync  run  stop  sync

/home/Kodi/.ttp/c:
aptitude  dir.dir  go  ip  lib  n  p  run  slow  start  stop  tsm  tsm32  tsm64  v  watchdog

J'ai supprimé tous ces fichiers et les entrées dans la crontab et j'espère qu'avec cela, le problème est résolu. Cependant, je serais intéressé par ce virus, comment je l'ai pu attraper (il pourrait être connecté à Kodi) et ce que je peux faire pour l'empêcher. Heureusement, il ne fonctionnait que depuis un utilisateur avec des droits limités, mais c'était toujours ennuyeux à gérer.


[~ # ~] modifier [~ # ~]

Bien que j'ai apparemment supprimé tous les restes de ce virus (j'ai également supprimé l'intégralité du dossier tmp), le virus revenait sans cesse. J'ai réalisé qu'il y avait une entrée dans ~/.ssh/authorized_hosts, que je ne me suis définitivement pas mis. Cela explique comment le virus pourrait être replanté à plusieurs reprises. J'ai supprimé l'entrée, désactivé la connexion pour cet utilisateur, désactivé la connexion par mot de passe (mot de passe uniquement) et j'utilise maintenant un port non standard.

J'ai également remarqué des tentatives de connexion répétées sur mon serveur avec des noms d'utilisateurs aléatoires, probablement par une sorte de bot (le journal ressemblait étonnamment à celui lancé depuis mon IP, envoyé par mon FAI). Je suppose que c'est ainsi que mon ordinateur a été infecté en premier lieu.

15
erik

J'avais la même chose. Le service a installé rsync et a obtenu des fichiers. J'ai trouvé un dota.tar.gz fichier dans le dossier utilisateur.

  1. refuser le port 22 sortant dans le pare-feu (par exemple ufw deny out 22)
  2. pkill -KILL -u Kodi (cela tue tous les processus en cours d'exécution de l'utilisateur Kodi)
  3. deluser Kodi
  4. supprimer userhome
  5. supprimer rsync (je ne l'ai pas utilisé)
  6. retirer /tmp/.mountfs*

Veuillez noter que cela ruinera probablement les choses pour Kodi. Au lieu de supprimer l'intégralité de l'utilisateur, vous ne pouvez probablement supprimer que dota.tar.gz (si c'est le cas) et le .ttp dossier (n'oubliez pas de nettoyer la crontab!)

Après un redémarrage, je ne vois plus de connexions sortantes (vérifiez avec:

netstat -peanut | grep 22

L'infection s'est produite via un utilisateur avec un mot de passe faible (compte Kodi avec le mot de passe par défaut peut-être?)

6
Sjors Nijhuis

Eu cette chose aujourd'hui. J'ai examiné le système et trouvé que mon système avait ses traces depuis environ un mois et je n'ai pas réalisé que cette chose était là jusqu'à ce que mon FAI m'en ait informé.

Les logiciels malveillants sont venus d'un utilisateur non sécurisé avec un mot de passe faible. Dans mon cas, c'était un utilisateur de timemachine. Le journal de pénétration ressemblait à ceci.

98341:Dec 23 23:45:36 fileserver sshd[23179]: Accepted password for timemachine from 46.101.149.19 port 45573 ssh2

C'est mineur XMRIG et un exploit qui scanne les autres IP pour les mêmes faiblesses. Ainsi, une machine peut infecter en cascade des dizaines d'autres. Vous pouvez jeter un œil à rapport MS sur cette cyberattaque .

La protection la plus efficace contre ce type d'attaques consiste à installer fail2ban sur votre serveur, en limitant l'accès ssh avec ufw, et utilisez la liste blanche ACL pour les systèmes qui peuvent accéder à SSH sur votre serveur.

1
Roman Savrulin

Dans mon cas, la source de l'infection était un utilisateur qui ne modifiait pas son mot de passe dangereux depuis la création de son compte (bien sûr, je lui ai dit de le faire). Mon serveur est probablement sur certaines listes: j'obtiens environ 1000 interdictions par semaine de fail2ban (essayez 4 fois avec un mauvais utilisateur ou mot de passe et soyez bloqué pendant un mois)

1
Sjors Nijhuis

J'avais le même malware. L'entrée se faisait via un mot de passe utilisateur non enregistré via ssh (port non défini par défaut), a été détectée et supprimée après environ 24 heures.

Dans mon cas, en supprimant la crontab de l'utilisateur, rm -rdf /tmp/.*, rm -rdf /home/user/.*, killall -u user était suffisant.

1
final

Voici ma solution (également nommée malware de crypo mining):

  1. pkill les emplois crontab
  2. nettoyer quelle que soit la description de cette tâche crontab pointant sur ie: /home/xxx/.ttp/a/upd>/dev/null 2> & 1
  3. supprimer /tmp/.xxx/.rsync/c/aptitude>/dev/null 2> & 1
  4. le plus important (cela me prend beaucoup de temps pour y arriver), sinon il continuera à revenir: exécutez crontab -e (pour cet utilisateur), vous trouverez ci-dessus le travail crontab est là, supprimez-les tous, enregistrez-le.
  5. changer le numéro de port.
0
Jack Ma