SPIP 3.2.17
Sur un de mes sites je trouve à la racine des fichiers étranges :
ha
core27109
response.php
/.device, comprenant plusieurs fichiers dont default.conf
Évidemment pour moi tout ça ne sent pas bon, mais l’un d’entre eux a des indications avec des références à des balises SPIP.
D’où ma question.
Merci de votre aide.
···
--
****Fin du message end - Signature****
Perline
Ce message est couvert par le secret de la correspondance
(art. 226-15 et 432-9 du Code pénal)
********************************************
+1, il faut faire le ménage, le plus efficace étant de chercher en cli avec la commande find les fichiers modifiés à la date des fichiers que tu as déjà repéré.
Pas suffisant.
Le bot (ou un des bots) qui exploite la faille est plus malin.
J’ai eu des sites affectés où des fichiers uploadés avaient eu leur date de modification changée pour correspondre aux autres fichiers du même répertoire (2017, 2020 etc, dans /ecrire et ailleurs).
Ha oui, belle fourberie, une alternative est de lancer un coup de spip_loader et de laisser son étape de nettoyage faire le ménage, et zou ? edit, non je dis de la merde.
Le plus safe, un peu comme quand on fait une mise à jour majeure cf Changer la version majeure de SPIP - SPIP : virer tous les dossiers de la dist (ecrire, prive, plugins-dist, etc), ne garder que les dossiers qui contiennent des données persos (IMG, conf, plugins), analyser ces dossier pour vérifier qu’ils sont safe, et relancer une install pour rétablir les dossiers et fichiers de la dist.
Pour le coup de spip_loader, j’y ai cru aussi et j’ai testé mais non.
En fait, il ne nettoie pas les fichiers uploadés qui n’ont rien à y faire.
J’ai pas regardé en détail le code mais on dirait qu’il ne compare que
les fichiers d’une distrib à l’autre.
C’est peut être une piste d’amélioration d’ailleurs, normalement on n’a
pas à mettre ses propres fichiers dans /ecrire et autres dossiers de la
distrib. Mais bon, y’a aussi /lib et /plugins/auto/saisies qui sont
ciblés par le bot, donc intérêt assez relatif.
De mon côté, sur des sites sensibles, je règle les droits d’écriture de
façon un peu stricte.
Apache n’a les droits d’écriture que sur /IMG, /local, /tmp, et
/config/fichiers, et pas plus (même pas /config pour les clés une fois
qu’elles sont générées).
Avec en plus un htaccess qui interdit l’exécution de tout fichier php
dans ces répertoires là.
Et la mise à jour de SPIP et des plugins est faite uniquement par git,
ce qui me permet de faire un git status pour vérifier si rien n’a été
modifié.
Mais ça demande du temps à mettre en place / tester, des compétences, et
un hébergement qui le permet.
Le 11/06/2023 à 19:43, b_b via Discuter de SPIP a écrit :
[b_b] b_b
Juin 11
Ha oui, belle fourberie, une alternative est de lancer un coup de
spip_loader et de laisser son étape de nettoyage faire ménage, et zou.
Même /plugins peut être touché (j’ai vu des ajouts de fichiers php vérolés dans /plugins/auto/saisies par exemple)
Donc à part /IMG et /config/connect.php, je dirais de tout supprimer (ou déplacer), réinstaller SPIP avec spip_loader par exemple, et au moment de la phase d’installation remettre /config/connect.php en place ainsi que /IMG, accéder à l’espace privé et réinstaller les plugins un par un.
chercher en cli avec la commande find les fichiers modifiés à la date des fichiers que tu as déjà repéré.
faut être ^pro pour comprendre
la version plus simple ?
Voir le sujet ou répondre à ce courriel pour répondre.
Vous recevez ce courriel car vous avez activé la liste de diffusion.
Pour vous désabonner de ces courriels, cliquez ici.
--
****Fin du message end - Signature****
Perline
Ce message est couvert par le secret de la correspondance
(art. 226-15 et 432-9 du Code pénal)
********************************************
Et bien c’est simple, tu as une version pas à jour de SPIP
et tu as été piratée.
Il faut impérativement installer la dernière version de sécurité 3.2.19 (ou mieux passer sur la 4.2.3 maintenue contrairement à 3.2).
Mais auparavant comme tu as été hackée et que tu as des fichiers vérolés il faut faire ce que dit b_b plus haut :
Les autres mesures énoncées par nicod sont peut être plus délicates, mais pas ça :
Cette mesure semble peu discutable et pas très complexe.
Est-ce que ça ne devrait pas alimenter un htaccess livré par défaut avec SPIP, en tant que .htaccess ou htaccess.txt à réutiliser comme celui à la racine ?
b_b: