bon, je n’ai qu’un site et je suis chez OVH
Le sam. 3 juin 2023 à 15:48, choucas via Discuter de SPIP <noreply@discuter.spip.net> a écrit :
Claire_HENRION:
l faut faire évoluer les maj en parallèle avec les versions de PHP
Et surtout penser que certains hébergeurs n’autorisent pas de fixer la version de php site par site, Dans ce cas, tous les sites hébergés doivent évoluer en même temps.
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
Pour info, une nouvelle vague de piratage a été lancée hier le 25/06. Cette fois, le hack consiste à déposer des fichiers python et autre binaire afin d’exploiter la machine pour miner du bitcoin. voici la liste des fichiers que j’ai pu repérer sur les différents sites impactés :
data.php hp_sniff.py* InUdrHFO.php Isotope.x86 mine tst.py x86_64 xmrig*
6diSibAbzNC4qNywNvKPq7IfcfxdyLvP7trJYdXG hp_sniff.py* killer.py mine* tst.py x86_64* xmrig*
Il est donc urgent de mettre à jour votre SPIP si ça n’est pas déjà fait, ou au moins à le protéger avec la dernière version de l’écran de sécurité cf Écran de sécurité - SPIP
Pour au moins un de mes sites qui ont subit le piratage, j’étais à jour:
Oui, effectivement, deux de mes sites ont été impactés.
Bonne journée !
Par curiosité: y-a-t-il possibilité que les sites aient été infectés avant la mise à jour en 4.1.10 avec un fichier resté caché et inaperçu ? je veux dire infectés alors qu’ils étaient dans une version antérieure, nettoyés puis mis à jour en 4.1.10, sauf que le nettoyage aurait laissé passer un truc ?
Ou alors ils n’ont jamais été infectés, mis à jour dans les temps et malgré ça infectés de nouveau ? et dans ce cas ça pourrait être une autre faille ?
Inquiétant tout ça !
Je pense que c’est du brut-force.
Les logs avant que le premier script ne soit déposé sont pleines de
31.222.238.89 - - [25/Jun/2023:20:37:37 +0200] "GET /spip.php?page=spip_pass HTTP/1.1" 200 13691 "-" "Go-http-client/1.1"
31.222.238.89 - - [25/Jun/2023:20:37:37 +0200] "POST /spip.php?page=spip_pass HTTP/1.1" 200 8747 "-" "Go-http-client/1.1"
Sinon dans les choses bizarres, j’ai un processus /usr/sbin/spip qui est exécuté (alors que le fichier n’existe plus) - il y a aussi des scripts python qui continuent à tourner même si le source est supprimé (seule solution : rebooter ou faire des kill manuels)
J’ai vu ça passer sur certains serveurs hier soir, pkill -9 -f spip et zou, mais il y a d’autres procs chelous comme /usr/sbin/systems et plein d’autres. De mon côté, un restart apache permettait de tous les tuer.
Par rapport aux appels excessifs de spip_pass, est-ce qu’il existe un plugin qui limite le nombre d’appels successifs ?
2 sites impactés.
Pour info le message d’OVH suite au piratage :
Problème rencontré : Un script malveillant a été détecté sur votre hébergement
Commande apparente : uCeuCEeuxFeuawDg??
Exécutable utilisé : /legacy/home/nomdedomaine/www/Isotope.x86
Horodatage: 2023-06-26 00:54:50
De mon côté aucun site à jour n’est impacté, le répertoire de ton site devait déjà être infecté avant ta mise à jour.
Ou alors, peut être, via un autre site pas à jour, suivi d’un déplacement latéral de site en site.
Bonjour à tous,
Nous venons de subir également un hacking de notre site 
Il était en spip_4.1.7. A priori le hackeur a déposé des script xmrig et autres scripts python avant de se faire repérer par ovh qui a bloqué les accès au site.
Avant de remettre le site sur pied on va modifier tous les mots de passe et upgrader en 4.1.10, quelle serait la meilleure méthode selon vous pour invalider tous les mots de passe des auteurs pour les forcer à en recréer un nouveau?
Merci pour votre retour
J’ai vu un client qui a perdu des répertoires entiers…
Oui, certaines attaques font ça aussi, dans ce cas il suffit de restaure une sauvegarde et zou.
Bonjour,
Faites attention, il peut aussi y avoir des fichiers vérolés dans le répertoire IMG !
Par exemple, un fichier php qui permet d’exécuter du code (eval("".base64_decode($b)).
Il pourrait s’appeler /IMG/about.php ou …
Bon nettoyage
Freed
Il est possible de réinitialiser et renvoyer le nouveau mot de passe par mail depuis la page auteur•rice.
Sinon, ce plugin s’il y a beaucoup d’auteu•rices Mots de passe expirables - SPIP-Contrib mais il faudra le désinstaller immédiatement après.
Bonjour
Pour information le script de ménage que j’ai codé est disponible sur la forge ouvert aux contributions annexes 
Cela se passe là : spip-contrib-outils/spip_cleaner: Clean spip instance after some hack - spip_cleaner - SPIP on GIT
c’est fait, merci pour le tuyau !
ClaireH
Le lun. 26 juin 2023 à 11:37, b_b via Discuter de SPIP <noreply@discuter.spip.net> a écrit :
Pour info, une nouvelle vague de piratage a été lancée hier le 25/06. Cette fois, le hack consiste à déposer des fichiers python et autre binaire afin d’exploiter la machine pour miner du bitcoin. voici la liste des fichiers que j’ai pu repérer sur les différents sites impactés :
data.php hp_sniff.py* InUdrHFO.php Isotope.x86 mine tst.py x86_64 xmrig* 6diSibAbzNC4qNywNvKPq7IfcfxdyLvP7trJYdXG hp_sniff.py* killer.py mine* tst.py x86_64* xmrig*Il est donc urgent de mettre à jour votre SPIP si ça n’est pas déjà fait, ou au moins à le protéger avec la dernière version de l’écran de sécurité cf Écran de sécurité - SPIP
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
Bonjour,
Pour information, ça fait déjà 2 sites que je vois totalement vidés de l’ensemble des fichiers après quelques jours de piratage :
Autrement dit, sans sauvegarde, le dossier squelettes/ le dossier IMG/ et plugins/ sont perdus.
Il ne reste que la base MySQL (et aucune base si c’était SQLite).
⇒ Mettez à jour !
Ça m’est effectivement arrivé il y a 2 semaines.
J’ai trouvé 2 éléments frauduleux sur la machine.
un script skdl.sh dans la racine de mon spip multisites, qui avait téléchargé des binaires dans /tmp, de la forme skl.aarch64 pour toutes les architectures, et « tenté » d’exécuter celle qui correspondait à la machine.
Intrusion le 26/06.
dans /var/tmp un répertoire .cpan-ecs-92d0 contenant des répertoires vides ET un .empty qui contenait :
-rw-rw-rw- 1 81 81 270 25 juin 14:02 cfg
-rw-rw-rw- 1 81 81 64 25 juin 13:05 cron
-rw-rw-rw- 1 81 81 31 25 juin 13:05 dir
-rwxr-xr-x 1 81 81 819K 20 févr. 2016 h64
-rw-rw-rw- 1 81 81 5 25 juin 13:06 pid
-rwxr-xr-x 1 81 81 181 3 oct. 2021 run
-rwxr-xr-x 1 81 81 3,5M 20 févr. 2016 run32
-rwxr-xr-x 1 81 81 4,5M 26 juil. 2017 run64
-rwxrw-rw- 1 81 81 226 25 juin 13:05 update
ainsi que 2 fichiers :
-rw-rw-rw- 1 81 81 336 25 juin 13:18 config.ini
-rw-r--r-- 1 81 81 50M 2 juin 10:14 system
Une crontab apache a été créée par le script autorun :
* * * * * /var/tmp/.cpan-ecs-92d0/.empty/update >/dev/null 2>&1
Tout cela issu d’une intrusion qui selon moi aurait eu lieu le 25/05 mais qui n’aurait été « activée » que le 26/06, soit juste un mois après, peut-être à cause d’un blocage de l’IP de l’attaquant pendant un mois. Je ne sais pas comment cette intrusion a été possible.
J’ai beaucoup de mal à croire à la coïncidence entre ces 2 intrusions mais les limites de mes compétences ne m’ont pas permis de trouver le lien entre elles, d’autant que je ne sais pas ce que font les binaires.
OVH a interrompu mon serveur juste quelques heures après les conséquences de l’attaque le 26/06, je n’ai pas eu la main sur la machine et n’ai donc pas pu étudier ce qui avait réellement été exécuté. Mais du coup je n’ai pas eu à subir un effacement complet. Tout ce que j’ai trouvé l’a été hors fonctionnement du serveur.
Mon SPIP n’était pas à jour depuis juste 1 an, en version 4.1.x
J’ai donc mis à jour depuis, installé l’écran de sécurité, renforcé mon filtrage (parefeu), et mis en place des alertes supplémentaires, ainsi qu’un système de surveillance de tout fichier modifié dans mon arbo /var/www.
Cela ne me garantie jamais rien à 100%, mais ça sera toujours mieux que sans.