Les premières étapes sont claires : Mettre le site est à jour (version 4.4.21 actuellement) et supprimer les fichiers suspects. Il faut idéalement en garder une copie, ainsi qu’une sauvegarde de votre base avant nettoyage et un export des logs (access log et error logs du serveur, ainsi que les logs SPIP) car cela sert de preuve et permet d’identifier l’étendue des dégâts
Mais ensuite, que reste-t-il à faire ?
Voici ce que j’envisage de dire aux victimes de ce piratage :
Le mécanisme d’attaque qui a été utilisé pour cette vague de piratages concerne un trou dans la protection de certains formulaires, sans qu’aucun identifiant n’ait besoin d’être utilisé. Cette attaque permet d’exécuter du code à distance (mettre des fichiers php qui peuvent faire presque n’importe quoi). La faille a été corrigée dans la dernière version de SPIP qui a été installé.
Maintenant ce qu’il faut faire :
Vos mots de passe pour se connecter à l’espace privé sont hashés. L’attaquant ne peut normalement pas retrouver directement le mot de passe à partir du hash. Mais il peut tester des mots de passe en mode hors-ligne par exemple (simplement en essayant des milliers de valeurs possible). Donc si votre mot de passe est simple, il faut le modifier (cf l’outil officiel de la CNIL Générer un mot de passe solide | CNIL).
Partez du principe que les attaquants ont pu récupérer tous les fichiers de IMG/. Si vous en avez qui contiennent des mots de passe, des données personnelles ou confidentielles, des documents internes, là il va falloir étudier précisément les conséquences de leur divulgation.
Les attaquants peuvent aussi avoir récupéré le contenu de votre base de données. Vérifiez que vous n’avez pas de mot de passe en claire dedans. Si oui, changez-les. C’est pareil s’il y a des clé api pour vous connecter à certains services externes. Regardez la configuration de vos plugins et s’il y a des identifiant ou des clés api, vous allez devoir les modifier.
Votre base de données n’est pas accessible de l’extérieur, mais pour anticiper d’autres attaques (peut-être via d’autres logiciels que vous utilisez), nous avons modifié vos mots de passe Mysql. Seuls les sites Spip sont mis à jour. Si vous avez d’autres logiciels, c’est à vous de faire la correction.
Donc pour faire bref, un site sain ne suffit pas. Si vous avez des données personnelles, il faut en informer les personnes concernées. Et il faut faire une rotation de tous les secrets auxquels le site pouvait accéder.
Est-ce que cela vous semble suffisamment clair et pertinent ?
C’est clair, oui et non… Pour exemple, mon site est très simple. Pas d’autres administrateurs que moi, les formulaires que je présentai concernaient juste des enquêtes très simples. Style : vous préférez le noir ou le rouge ? Par conséquent, il me semble que, dans cette situation, seul le mot de passe d’administrateur doit être modifié, si je comprends bien. Je précise que j’ai réinstallé l’ensemble des plugins.
Le message général me paraît bien (je viens de passer quelques heures à réparer un site victime de cette vulnérabilité).
Je me rends compte un peu tard qu’il y a effectivement les codes d’accès à la BDD en clair dans les fichiers de spip (connect.php). Du coup, il est possible que ma BDD ait été compromise.
Si je restaure une sauvegarde, elle ne sera pas compatible avec la nouvelle version 4.4.21. Si je fais tourner le spip_loader ensuite, est-ce que cela suffira ?
S’il y a eu une intrusion sur ton site qui a permis d’afficher le contenu de connect.php, le mot de passe de connexion à ta base de données a certainement été récupéré, car il est en clair (c’est une limitation de PHP). Si c’est le même mot de passe que celui de ton hébergement / email d’hébergement, il faut envisager que ton compte sert déjà à émettre du spam et que n’importe quoi est stocké sur l’espace d’hébergement…
Complément : certains hébergeurs (c’est le cas d’infomaniak) proposent un phpmyadmin accessible sans mot de passe (l’url est https://phpmyadmin.hosting-ik.ch/) => Avec le contenu de connect.php un attaquant peut mettre n’importe quoi sur votre site, quasiment sans limite.
J’essaye d’abord de trouver un outil qui me permette de comparer rapidement avec un état antérieur de la bdd. Quelque chose qui me résumerait les changements sous forme de requêtes sql, je ne sais pas si ça existe. Sinon, je restaurerai une sauvegarde, pour être tranquile.
Avant toute action il faut commencer par désactiver le domaine original du site, sans ça les webshell et autres scripts déposés lors du piratage pourront être exploités par les attaquants. Ensuite, pour lancer la mise à jour il faut créer un sous domaine temporaire qui pointe sur le site, ainsi on ne l’expose pas aux attaquants. Mais, le plus propre est de repartir d’une installation propre et d’y réinjecter les données (IMG, squelettes) après les avoir analysé et nettoyé. Pour les plugins, je recommande de les réinstaller à partir de SVP, c’est bien plus simple que de passer du temps à nettoyer le tout.
J’avance, j’avance… Enfin j’espère. Vous allez peut-être me trouver la solution super rapidement. Je pense avoir fait tout correctement. C’est à dire : suppression de l’ensemble des fichiers sur le serveur. Vide, plus rien, nada… Puis réinstallation propre avec un nouveau spip_loader. Puis changement du mot de passe de la base SQL depuis l’interface AlternC (chez notre ami de Webelys) j’ai lu quelque part qu’elle était vraisemblablement corrompue, puis installation d’une ancienne sauvegarde SPIP 4.4.20 sur le serveur. Puis appel du site par son URL pour activer les pages d’installation.
Alors victoire ! Cela semble fonctionner. Mes articles apparaissent dans le back-office, mais curieusement j’obtiens cela en Front-office : « Not Found The requested URL was not found on this server. »
Je dois avoir oublié un truc, un bidule ? Merci beaucoup pour votre travail
Il manque peut-être le .htaccess. Quand Spip s’installe il y a un htaccess.txt qu’il faut dupliquer (ou renommer) en .htaccess (sans extension) pour que la ré-écriture d’url fonctionne.
Quand ce fichier est absent cela donne ce genre d’erreur … à tester ?
Ben voilà ! Super. Merci. Je savais que j’avais oublié un bidule. Cela faisait trop longtemps que je n’avais pas effectué une installation complète de mon SPIP. Merci encore.
Je suis d’accord, c’est pour moi la solution la plus simple/sûre/économe en ressources : renommer l’ancien dossier pour qu’il ne soit plus accessible aux attaquant·es et réinstaller la dernière version de SPIP + plugins dans dossier vide.
Merci pour le détail de la procédure.
Est-ce que c’est possible de fermer rapidement un site en renommant un fichier, du genre spip.php en spip_old.php ou txt…, ou est-ce qu’il faut plutôt modifier le htaccess ?
ceux qui remplacent des pages ou rajoutent des choses à servir sur des sous-domaines et qui ne s’activeront que lors d’une requête http/https;
ceux qui utilisent le serveur pour faire tourner du soft autonome type minage de bitcoins.
Remplacer spip.php par spip.php.old ne servira qu’à empêcher les accès légitimes. Pas tous les autres. Et ça n’arrêtera pas tous les processus malveillants qui peuvent déjà tourner. La dernière vague de piratages a produit les deux types.
Le meilleur moyen et le plus sûr est de tout bloquer par .htaccess, par exemple en interdisant toutes les IP sauf la sienne, ou a mettre temporairement un mot de passe sur la racine du site.
Je ne suis pas experte de ces hébergements, j’utilise mes propres serveurs, mais c’est comme ça que je fais (à la différence que je traite le problème directement dans la configuration du vhost d’apache).
Merci pour vos réponses.
En fait, après avoir modifié le nom du répertoire du site, je veux interdire l’accès à tout le monde, et continuer mes suppressions de fichiers sur ftp.
Le mieux c’est peut-être deny from all dans le htaccess à la racine de ce dossier, non ?
justement, moi j’avai commence une sujet pour apprendre a mieux sécurise un site, car, que cela soit avant ou après le piratage, je pense qu’il est bine de le sécurise au max.
De mon cote, je regarde pour supprimer tout formulaire… car on en a pas besoin, du moin dans les structures dont je m’occupe, et pour les cas on a besoin scinde cela sur un autre outil
exemple, j’ai des structures avec :
SPIP
Paheko
PodCloud
Brevo
pour les formulaires je suis en evaluation de plusieurs solutions, mais il y a 0 lien entre ces outils… juste le DNS pour pointer en sous domaine …
Oui, je sais que ca demande un peu de technique, mais les roles sont bien scindes, et si un tombe… les autres ne sont pas affectes…
