Bonjour,
Tout est dans le titre.
Un client subit sur son site des modifications de fichiers.
Je ne sais plus quoi faire car ça recommence malgré réinstallation propre.
Merci de votre aide.
Probablement pas complètement… Après avoir été hacké une première est-ce que tout a bien été supprimé sauf les dossiers IMG et squelettes (et ont-ils été bien nettoyés) Et comme dit dans d’autres messages peut-être aussi un cron à nettoyer ? Et dans certains cas redémarrer le serveur (action hébergeur)
Bonjour,
Donc pour moi en situation identique, chez OVH mutualisé, j’ai changé de version PHP pour faire redémarrer le site sur un autre serveur. Alors la tâche CRON est supprimée.
Bonjour, situation identique chez moi. J’ai réinstallé une version propre, gardé seulement mes images et mes squelettes. De nouveaux des injections.
Bonjour,
En vérifiant le contenu de IMG et squelettes ?
Avec un changement de version de PHP (aller/retour) pour redémarrer le serveur web ?
En vérifiant les cron linux ?
Tout ça a été fait sans aucun succès… Injection ce jour d’un fichier jeton google et d’un dossier.
Bonjour,
Même situation pour moi il y a 2-3 semaines, l’hébergement complètement vidé, même le dossier www, il était recréé dans les 30 secondes.
C’est une tâche CRON chargée sur le serveur qui se relance systématiquement.
Où es-tu hébergé ?
Pour moi chez OVH mutualisé, la solution a été de changer de version de PHP (passer sur la plus vieille dispo) afin de changer de serveur et donc de tuer la tâche CRON. Puis après 10 minutes revenir à ton serveur d’origine.
Merci Stéphane. J’ai appliqué ta procédure. A suivre…
Bonjour,
j’ai aussi ce probleme sur le site d’un client.
J’ai refait une installe propre, en ne gardant que les squelettes, images et plugins.
J’ai changé le chemin de base du site web, et je le deploie depuis git.
Mais, je continue d’avoir le meme probleme:
c’est plutot pas mal fait, ca injecte une pub, mais le fait de supprimer le .htaccess plante les liens, donc pourrait mieux faire 
peut etre aurais du reinstaller les plugins 1 par 1 plutot que garder les fichiers, mais c’est quand meme surprenant.
Spip et tous les plugins sont a jour.
Composed-By: SPIP 4.3.5 @ www.spip.net + spip(4.3.5),aide(3.2.5),archiviste(2.2.3),compagnon(3.1.5),dump(2.1.4),images(4.2.2),forum(3.1.11),mediabox(3.1.9),mots(4.2.2),plan(4.1.4),porte_plume(3.1.8),revisions(3.1.9),safehtml(3.1.3),sites(4.2.2),stats(3.1.9),urls(4.1.6),couteau_suisse(1.16.1),verifier_plugins(1.4.1),breves(3.1.3),yaml(3.1.2),verifier(3.3.0),facteur(5.2.0),socialtags(4.1.0),spip_bonux(4.2.0),simplog(2.1.0),select2(2.1.0),saisies(5.10.0),cextras(4.2.1),iextras(4.2.0),iterateurs(1.0.6),queue(0.6.8),jquery(3.6.4),csstidy(1.15.1),minidoc(1.0.3),ordoc(1.1.2),mejs(4.2.7),phpmailer(6.5.3),bigup(3.2.14),compresseur(2.1.7),medias(4.3.4),svp(3.1.11),tw(3.2.1),mailshot(3.4.0),accesrestreint(6.1.0),mailsubscribers(3.7.0),newsletters(2.2.0)
Je me demande quand meme s’il n’y a pas une faille quelque part dans un des plugins…
EDIT: j’en ai profité pour passer de php 8.2 à php 8.3 chez ovh, et activer le pare feu applicatif. C’est du mutu, donc pas d’acces direct au crontab, et je ne vois pas comment le hacker y aurait acces non plus de toute facon. A noter que l’attaque n’a lieu que tous les 2/3j, ca a l’air d’etre presque du manuel.
Bonjour,
Donc changé le dossier d’hébergement du site style www ?
Et qu’est-ce qui est recréé ? l’original ou le nouveau ?
Quel est ton hébergeur ?
Comme dit précédemment, d’autant que si le site est en rade, il faut essayer de changer vers une très vieille version de PHP pour forcer à changer de serveur et donc tuer la tâche CRON mise en place par le hack.
oui, je suis passé de www à <autre chose :D>
le site est sur ovh mutualisé
j’ai aussi renommé l’ancien repertoire www, pour aussi contrer une eventuelle tache cron (mais encore une fois, sur un mutu ovh, on ne peut pas creer de tache cron…)
et j’ai aussi switché de php 8.2 à 8.3, mais ca je ne suis pas sur que cela change grand chose, car tu peux tres bien switcher de version php sans redemarrer un serveur, d’autant plus sur un serveur mutualisé, c’est géré autrement.
Et bien sur, c’est dans le nouveau site que le hack est appliqué de nouveau, donc imo ca passe par l’http, pas par le filesystem.
je pense que je vais supprimer puis resinstaller tous les plugins, je ne vois que cela qui reste.
Oui ok, mais je voulais dire par ssh…
Comme écrit plus haut, j’ai été hacké sur un OVH mutualisé. J’ai renommé le dossier www, mais il était recréé par le hack dans les 5 secondes (donc tâche CRON), et ceci avec un site complètement vidé par mes soins !
J’ai tué la tâche en créant un fichier .ovhconfig définissant une vieille version PHP.
le www n’est pas recréé, mais les fichiers sont modifés dans le nouveau www, www_clean (pas exactement ca, mais c’est l’idée).
Bonjour,
J’ai appliqué cette procédure de changer et rechanger la version php et visiblement, plus de problème. Merci !
Gil
Bon moi pour l’instant cela me gave, mais j’ai fait bon usage du message de @Graphie pour ajouter un cron qui execute un script sh toutes les heures pour faire un git hard reset… au moins ca limite l’impact du hack, qui arrive toujours tous les 2/3j
Bonjour,
Mais on ne sait toujours pas si tu as fait usage de cette méthode :
oui j’ai changé la config, mais ca n’a rien changé, et je ne vois vraiment pas pourquoi ca marcherait, comme je l’ai expliqué plus haut. Les tentatives de hack ne sont de plus pas executées régulierement.
@jlv et c’est bien la version 4.3.5 de SPIP ? Avec tous les plugins à jour ? Et pas de php dans les squelettes ?
Parce que, si c’est le cas, ça voudrait dire qu’il y a une faille inconnue exploitée. Et ça serait bien de faire appel à la @Security_Team pour trouver et corriger le problème.