Virus ?

Support Debian
#1

j’ai installé il y a qq temps Debian Wheezy sur le PC d’un ami sur lequel je peux accéder via ssh. Il dispose du mdp root mais normalement ne l’utilise pas.

Ce PC lui sert en bureautique et accès internet classique et me sert à différents essais distants, le principal étant le proxy squid.

Je constate depuis hier un phénomène étrange et non expliqué à ce jour.

Via top, j’observe l’existence d’un processus avec un nom bizarre, aoqbmbgisv en ce moment.
Via ps -ef | grep [pid du processus en question] , je découvre le nom d’une commande système connue ( sh en ce moment )
Via netstat -antp : il y avait ( voir Essai 3 ) une connexion établie sur une adresse IP inconnnue.

Essai 1 - kill
le processus meurt et revient avec un autre nom associé à une autre commande, par ex : sleep, netstat, …

Essai 2 - déconnexion du réseau
le processus passe de ~20%CPU à ~100%CPU

Essai 3 - ‘DROP’ via iptables de l’IP en question
le processus passe de ~20%CPU à ~0,3%CPU mais reste toujours présent et se régénère lorsque je le tue ( Essai 1 )

J’en suis là et aimerais vos commentaires éclairés …
Merci d’avance.

#2

Salut,

Il serait bénéfique de nous faire part de tes retours console et de nous en dire un peu plus ce processus aoqbmbgisvet ce fichier (?) sh
Leurs contenus, aussi.

Cela dit, je ne vois pas trop le rapport avec ton titre.

#3

Salut BelZéButh,

merci de t’intéresser à mon sujet.

Pour le titre, j’ai pas trouvé mieux, si tu penses à une meilleure, fais moi le savoir …

Pour le reste j’ai tout dit ce que je sais, j’ai trouvé … en particulier je n’arrive pas à avoir d’info sur aoqbmbgisv
… mais en te lisant j’ai peut oublier de rechercher via le nom du pg ( sh par exemple ) … à suivre
Suis preneur de tes idées également.

A+

#4

Cela ne répond guère à ma requête.
Nous n’avons toujours aucun élément concret à nous mettre sous la dent.
Dans ces conditions je me vois obliger de réitérer ma demande initial.

Dans le cas contraire, je ne vois pas comment on pourrait t’aiguiller, sans un os à ronger …

#5

RKhunter …
Je suppose que le PC n’est pas allumé en continu ?
Trouve ou se trouve cet exécutable, quand a t il été créé.
Demande si l’utilisateur a remarqué quelque chose, s’il a fait un truc particulier, …

Mais oui ça a tout l’air d’être un programme illégitime.

#6

Merci Mimoza pour ton retour.

RKhunter … - :slightly_smiling: voir ci-dessous
Je suppose que le PC n’est pas allumé en continu ? - il l’est depuis l’apparition du problème
Trouve ou se trouve cet exécutable, quand a t il été créé. - rien trouvé pour l’instant
Demande si l’utilisateur a remarqué quelque chose, s’il a fait un truc particulier, … - rien a priori

RKhunter - je ne connaissais pas et après un 1er rkhunter -c il me retourne 3 pistes à creuser que je partage ci-dessous avant analyses complémentaires :

  1. The command ‘/usr/bin/unhide.rb’ has been replaced by a script: /usr/bin/unhide.rb: Ruby script, ASCII text
  2. Found enabled inetd service: swat
  3. Hidden directory found: ‘/etc/.java’

A suivre

#7

Ont avancent guère pour autant. :033
Aurais-tu des trucs à nous cachés du fait de ta résistance à la non divulgation des retours console …

Notes :

[20:01:10] ~ # ash rkhunter
(...)
Recommande: (...) unhide (...)

[20:00:28] ~ # ash unhide
Paquet : unhide                                         
État: non installé
Version : 20121229-1+b1
Priorité : supplémentaire
Section : admin
Responsable : Debian Forensics <forensics-devel@lists.alioth.debian.org>
Architecture : amd64
Taille décompressée : 3 253 k
Suggère: rkhunter
Description : Forensic tool to find hidden processes and ports
 Unhide is a forensic tool to find processes and TCP/UDP ports hidden by rootkits, Linux kernel modules or by other techniques. It includes two utilities: unhide and unhide-tcp. 
 
 unhide detects hidden processes using the following six techniques: 
 * Compare /proc vs /bin/ps output 
 * Compare info gathered from /bin/ps with info gathered by walking thru the procfs. 
 * Compare info gathered from /bin/ps with info gathered from syscalls (syscall scanning). 
 * Full PIDs space occupation (PIDs bruteforcing) 
 * Reverse search, verify that all thread seen by ps are also seen by the kernel (/bin/ps output vs /proc, procfs walking and syscall) 
 * Quick compare /proc, procfs walking and syscall vs /bin/ps output 
   
 unhide-tcp identifies TCP/UDP ports that are listening but are not listed in /bin/netstat through brute forcing of all TCP/UDP ports available. 
 
 This package can be used by rkhunter in its daily scans.
Site : http://www.unhide-forensics.info

Étiquettes: implemented-in::c, interface::commandline, role::program, scope::utility, security::forensics, security::ids

[20:00:40] ~ #
#8

BelZéButh tes explications sont aussi claires que ce que je cache :slightly_smiling:

Ceci dit, ça avance … doucement.

rkhunter, je ne connaissais pas et j’ai corrigé par :

  • rkhunter --propupd photo initiale
  • rkhunter -c --enable all --disable none 1er test

Ce qui m’a fait apparaître d’autres warnings :

  1. The command ‘/usr/bin/unhide.rb’ has been replaced by a script: /usr/bin/unhide.rb: Ruby script, ASCII text
  2. Found enabled inetd service: swat
  3. Hidden directory found: ‘/etc/.java’
  4. Process ‘/sbin/dhclient’ (PID 10364) is listening on the network.
  5. Process: /usr/bin/edcirhhiuk PID: 7132 File: /usr/bin/edcirhhiuk use deleted file.
    et ceci 5 fois, cad avec 5 PIDs différents !

Concernant unhide.rb : il n’a rien retourné.

et donc en point d’étape :

  1. a priori normal
  2. éliminé, sans influence sur le pb
  3. ?
  4. ?
  5. les bizarreies continuent -> à creuser …
#9

Point d’étape n°2 :
J’ai retrouvé le fichier vu avec top, il se trouve dans /usr/bin.

En ce moment le fichier se nomme : fttxpiagoh

Dans /usr/bin je vois :

-rwxr-xr-x  1 root   root      618642 mai    7 20:17 fttxpiagoh
-rwxr-xr-x  1 root   root           0 mai    6 09:40 onqlytcagw

et apparaît toutes les qq s

-rwxr-xr-x  1 root   root      618653 mai    7 20:17 [autre suite de 10 lettres qui change à chaque nouvelle apparition]

reste à comprendre comment sont créés ces fichiers …

#10

Mes fesses. :033
Un copier/coller des retours console que tu invoquais, S'il te plaît.

# ps -ef | grep
# netstat -antp

Dans le cas contraire et après quoi, je passerai mon chemin …

* edit *

Ce n’est vraiment pas joli, tout ça …

Déconnectez, la box machin-truc et/ou le Wiifi.

#11
  1. regarde ce qu’il y a dedans mais je pense que tu peux le supprimer, il ne doit pas y avoir de répertoire/fichier caché dans /etc
  2. Je dirais normal, c’est le client DHCP qui te permet d’obtenir une adresse sur le réseau, mais normalement il ne devrait pas écouter … enfin je pense
  3. C’est clairement là que le problème est. Le fait qu’ils aient été créé en tant que root ne me dit rien qui vaille. La solution la plus sûr dans ce genre de situation est la réinstallation complète.
#12

Bonjour Mimosa,

merci pour ton retour, je suis 100% d’accord avec toi mais pour l’instant je ne veux pas réinstaller, je préfère continuer à comprendre …

et pour info ça progresse, voici donc le point d’étape n°3 :
A)

cd /etc/inet.d ; ls -lart ;
-rwxr-xr-x   1 root root  7820 déc.  22 21:59 apache2
-rwxr-xr-x   1 root root   323 avril 16 15:45 dsqsreozlb
-rwxr-xr-x   1 root root   323 mai    7 20:17 fttxpiagoh
drwxr-xr-x   2 root root  4096 mai    7 20:17 .
drwxr-xr-x 139 root root 12288 mai    7 20:17 ..
-rw-r--r--   1 root root  1633 mai    7 20:17 .depend.stop
-rw-r--r--   1 root root  2091 mai    7 20:17 .depend.start
-rw-r--r--   1 root root  1774 mai    7 20:17 .depend.boot

B) Par ailleurs vu avec netstat
il y a en permence ( ~1s ) des tentatives de connexion ( SYN_SENT ) sur l’IP DROPée par iptables.
J’ai capté des connexions ( ESTABLISHED ) sur 2 autres IP inconnues.

Et donc en 1ère conclusion ( j’ai bien dit que cela progressait )

  • le problème semble être apparu le 16/04/2015
    manifestement le compte root a été piraté
    le kill du pg bizarre ne sert à rien car il est probable qu’il lance de suite un fork qui reprend la main si le père disparaît
    tout semble claire et j’imagine qu’en nettoyant /etc/init.d et /usr/bin cela devrait résoudre le pb ( sans réinstallation ) mais pour l’instant je préfère continuer à creuser, j’aimerais comprendre comment le root a pu être piraté … et imaginer une capacité à riposter ?

Toutes idées pour balancer qq skuds à l’inconnu m’intéressent, si le forum n’est plus totalement adapté à cette discussion je viens de créer un mail spécifique virus_debian@yahoo.com.

#13

Juste pour renseigner le bon peuple, si l’origine du problème a été identifiée, ce serait sympa de signaler (dans la limite de ce qui est publicisable) quelles sont les (mauvaises) manipulations qui peuvent conduire un système plutôt réputé comme bien protégé (linux - Debian) à se faire contaminer par des trucs qui tournent avec les privilèges de root.

#14

Cela va de soi.

Je pense déjà que l’exemple et la démarche pour identifier le pb sont très instructifs.

Comme je l’ai écrit j’imagine que le mdp root a été trouvé. Comment ? Je ne sais pas, l’investigation complémentaire fait l’objet de mon 2ème post …

Ceci dit je suis sous linux depuis plus de 15 ans et je n’ai jamais eu de problème, en l’occurence ce n’est pas mon PC et je ne pourrai jamais savoir avec certitude ce qu’à fait l’utilisateur final qui disposait de ce mdp, car c’est son PC, mais qui n’a pas les compétences pour gérer seul son poste.

#15

L’administrateur de la dite machine, qui somme toute, n’a pas les compétences requises.
Et pour ce faire griller une [mono]Debian[/mono] derrière une box_machin-truc, il faut y mettre de la bonne volonté, cela n’est pas à la portée de tout le monde … :033

#16

Je doute fortement que l’intéressé se connecte directement sur la machine en question. Les IP que tu as relevés sont plutôt des PC ou proxy qui servent de passerelle. Donc avant d’attaquer récupère un max d’info pour ne pas pourrir un innocent. :unamused:

#17

Of course Mimoza, c’est bien pour ça* que je suis toujours dans la collecte d’infos et l’analyse …

*et que je n’ai pas publié les IPs en question ( 2 aux US, 1 près de Denvers, l’autre de Santa Fe et la 3ème au Japon près de Tokyo )

PS pour BelZéButh : j’attends tes commentaires sur mon 2ème post, là tu as un vrai retour console :smiley:

#18

Point d’étape 3 :
ma 1ère conclusion était trop optimiste.
J’ai nettoyé /etc/init.d et /usr/bin et tout est revenu ! ?

#19

Ça a l’air d’un rootkit genre suckIt. Essaye de voir avec

for i in $(seq 1 65536) ; do if [ -f /proc/$i/cmdline ] ; then ls -d /proc/$i; fi ;donesi tu as un retour genre ls: impossible d'accéder à /proc/373: Aucun fichier ou dossier de ce typec’est un processus caché. Tu as d’autres façons de le planquer mais celle ci est la plus répandue.

#20

Bonsoir fran.b,

Merci de ton avis.

j’ai essayé ta cde, tout est normal ! :frowning:

Pour info, le point d’étape 4 qui n’apporte pas grand chose.

  1. d’autres IP pirates sont apparues, dont plusieurs en Chine / Nanjing, … via netstat je n’en ai vu aucune connectée, mais via ntop toutes ont un volume échangé ( entre qq 100o à qq 10Ko )
  2. j’ai fait une 2ème tentative en nettoyant les répertoires concernés et coupant l’alim du PC afin d’être sûr que le virus n’est pas reconstruit lors du shutdown … et non la situation est toujours identique
  3. sur l’un de mes serveurs ( donc chez moi cette fois ), je me suis aperçu ( avec rkhunter ) que je n’avais pas de fichier auth.log. Je l’ai remis en servie immédiatement mais je ne comprends pas. Peut-on imaginer que je me suis trompé lors de l’install ( mes début avec lxc ), que … ( j’ai d’autres Warnings mais n’ai pas encore eu le temps de les analyser et d’imaginer que les problèmes seraient liés )
  4. j’ai installé sshrc sur mes postes pour pister les connexions ( parasites ) …
  5. je sais que j’ai encore plein de choses à faire pour améliorer la sécurité, mais pour l’instant j’essaie toujours de comprendre d’ou est venu le problème et l’éradiquer sans reconstruire le système.