Je n’ose comprendre : il a COPIE une partie du disque ? C’est à dire qu’il a manuellement eu ACCES aux fichiers que son script n’avait pas récupéré ? Cette idée me terrifie !
Je comprends bien ce que tu veux dire. Dans mon cas, les sites ont aussi été bloqués par OVH, mais ce sont des sites installés sur des serveurs mutualisés ; en conséquence, je n’ai accès qu’au ftp racine du site, le reste est de leur responsabilité. Cela explique d’ailleurs certainement que les sites ont été bloqués dans la minute suivant le passage du pirate.
reçu par mail automatique immédiat d’OVH :
Problème rencontré : Un script malveillant a été détecté sur votre hébergement
Commande apparente : xFeuFDeuuCeu#
Exécutable utilisé : www/Isotope.x86
Horodatage: 2023-06-26 00:53:23
Je me suis donc uniquement assuré de réinstaller un contenu correct à la racine de www/
Bien sûr, je ne sais pas encore si les sites sont encore vulnérables, malgré le nouvel écran de sécurité 1.5.3 et les nouveaux mots de passe.
Il est impossible d’être certain à 100% qu’un site est safe. Car des pirates peuvent exploiter des failles qui n’ont pas été remontées à l’équipe de dev. La seule conduite à avoir pour réduire cette incertitude est de faire des mises à jour dès qu’une version est publiée. Je pense qu’à terme la solution sera d’inclure un script de mise à jour automatique comme on le trouve dans Wordpress (malgré le risque de faire planter un site, c’est toujours plus safe que de laisser une version obsolète en ligne 
)
Oui, merci gild, je comprends qu’il s’agit bien de deux choses différentes.
Sur mon serveur chez Gandi, j’ai en effet deux sites mutualisés dans un dossier vhosts. Seulement l’un des deux sites (le site le plus important en SPIP) a été touché.
J’ai changé la plupart des mot de passe (serveur, phpmyadmin…)
Je m’apprête à effectuer ce qui m’a été conseillé ici, à savoir uploader le spip_loader.php à la racine du site en question, qui pour le moment ne contient qu’un répertoire /htdocs vide (suite à l’effacement de son contenu par le pirate).
Je vais donc mettre à jour la version de SPIP vers une version plus récente, en espérant que cela ne pose pas trop de soucis de compatibilité avec les plugins entre autre… J’utilisai par example le plugin Commandes, qui semble être encore stable en v.4.1… on verra…
Je donnerai des nouvelles ici de comment cette tentative de récupération de mon site fonctionne pour moi…
Bonne journée à tous.
Bonjour
je gère une quinzaine de WP et ils sont paramétrés pour faire les maj mineurs en auto, les majeurs sont manuelle, les plugins sont en auto aussi sauf certain que je préfère lancer à la main
il arrive qu’un site plante mais ce n’est jamais une maj du core, en général c’est un plugin…
et je suis avertie de suite par un mail
pour défendre les WP j’utilise un plugin dédié « Wordfence » et pour certain clients importants en version payante
c’est lui qui fait le boulot et il est redoutablement efficace pour stopper de multiples tentatives d’injection
et surtout il bloque les ips , il scanne les dossiers/fichiers et, vérifie l’intégrité et les failles de plugins, envoi des mails de suivi, etc…
c’est en effet là la supériorité de Wordpress car le modèle gratuit / payant permet à des entreprises de se spécialiser dans un domaine et d’offrir une version « light » gratuite et une version complète payante
A mon avis, tu devrais commencer par une réinstallation de SPIP 3.2 avec les anciens plugins. Pour savoir s’ils sont compatibles SPIP 4.1, je t’invite à suivre les étapes indiquées sur Vérifier ses plugins avant un changement de version de SPIP - SPIP-Contrib
1 « J'aime »
Merci, il me semble que c’est peut-être plus sage en effet, de faire d’abord l’installation de SPIP 3.2 et puis 4.1 par la suite, après vérification de compatibilité pour tous mes anciens plugins. Merci pour le lien !
Je n’arrive cependant malheureusement pas à lancer l’installation avec la dernière version de spip_loader que j’ai mis dans /htdocs…
J’ai actuellement PHP7 et MySQL 5.6… Est-ce lié à cela? Dois-je faire une mise à jour ?
Voici en image le résultat d’erreur qui s’affiche sur la page monsite.tld/spip_loader.php
Bonjour,
c’est un problème avec l’instance de Gandi. Vous pouvez voir avec eux pour relancer l’instance sinon il faudra mettre à jour à la main ou monter une autre instance pour migrer le site.
1 « J'aime »
itou chez Gandi
un site hacké et tous les autres sites de l’instance en grande difficultés
- pas moyen de faire de mise à jour (erreurs meme avec les spip_loader de l’époque)
- lenteurs extrèmes (des dizaines de secondes à chaque page)
La seule issue possible : mettre à jour l’instance vers php8.x,
mais bien-sur il faut que les plugins soient compatibles et bien-sur certains sites ne supporteraient pas l’évolution, donc en stand-by pour l’instant
On peut toujours s’en sortir en :
- déplaçant tous les fichiers dans un sous dossier (vieux_spip par exemple)
- mettant spip_loader.php à la racine
- installant avec ce dernier les fichiers de SPIP version voulue
- et, avant de lancer l’installation, remettant config/connect.php, IMG, plugins/* et squelettes
bon a la limite si les plugins soient compatibles peut-etre…
mais encore il faut pouvoir utiliser spip_loader.php et aucune version ne fonctionne por moi …
Je viens d’échanger avec Gandi et en fait l’erreur était due au fait que, comme le site a été hacké et a émis des connexions sortantes suspectes, ils l’avaient bloqué…
Après déblocage, la page de l’installation est apparue…
Je continue, et j’installe donc la version SPIP 3.2.19 comme l’ont conseillé RealET et epilibre.
A suivre…
spip_loader.php a donc fonctionné pour moi… après déblocage par mon hébergeur.
avec quelle version de spip_loader ?
La dernière il me semble, la version 6.1.2.
Bon courage !
Bonjour, mon site chez OVH a été piraté hier. Ovh a bloqué le site et j’ai reçu ce message :
Il est possible qu’un script malveillant présent sur votre hébergement soit à l’origine de cette exécution. Si vous n’êtes pas à l’origine de l’exécution de ce script, cela signifie qu’il y a une faille sur votre site et qu’un hacker s’en est servi pour réaliser cette opération.
Notre système de surveillance a détecté une opération irrégulière au niveau de votre site. Ce message a pour but de vous alerter sur le fait que votre site et vos données peuvent encourir un risque.
Par mesure de sécurité, nous venons de bloquer l’accès à votre site, cependant, l’accès à votre espace d’hébergement (FTP) reste tout de même accessible.
Vous trouverez ci-dessous les détails techniques de cette opération :
Problème rencontré : Un script malveillant a été détecté sur votre hébergement
Commande apparente : /usr/sbin/rsyslogd -n -iNONE
Exécutable utilisé à supprimer : www/x86_64
Ouvrez le logiciel FileZilla puis connectez-vous à votre espace de stockage FTP. Cliquez ensuite sur Serveur dans la barre de menu, puis sur Entrer une commande FTP (l’intitulé peut être différent suivant la version de FileZilla que vous utilisez) :
Dans la fenêtre qui s’affiche, renseignez la commande ci-dessous puis validez-la : SITE CHMOD 705 /
Une réponse « 200 Permissions changed on / » confirme que la manipulation s’est bien effectuée. Pour le vérifier, essayez à nouveau d’accéder à votre site web.
Après une 20 minute, le site est de nouveau actif.
En espérant que cette solution soit applicable pour vous et en attendant qu’un correctif arrive. Merci à vous
Merci pour ce retour d’expérience… qui j’imagine peut servir dans certains cas.
Une question : pouvez-vous me dire quelle était la version de SPIP que vous utilisiez pour ce site ?
C’est la version : SPIP 3.2.16
1 « J'aime »
Encore moi ! la solution d’Ovh a fonctionné quelques heures… le site est de nouveau en rade.
à suivre.
Est-ce que tu as fait le ménage ou, mieux, réinstallé intégralement SPIP pour être sûr·e qu’il n’y ait plus de fichiers douteux ? Car, s’il reste des fichiers vérolés, l’exécution du script peut reprendre comme si de rien n’était.