Bonjour à tous,
A l’occasion d’une connexion FTP vers mon répertoire d’hébergement OVH, j’ai découvert un ensemble de fichiers (tous en php) suspects à la racine de mon SPIP mutualisé en 3.2.8. (je sais)
Est-ce que quelqu’un peut me faire un petit audit sur ces fichiers et ce qu’ils ont potentiellement tenté de faire ?
L’autre question sera de savoir comment ils sont arrivés là.
Apparemment, ils sont identiques à l’exception du dernier, data.php qui fait allusion à des répertoires SPIP précis.
Je vous partage un lien vers les fichiers zippés dans le post qui suit.
A noter qu’ils ont tous été créés sur un intervalle de temps d’un quart d’heure.
Le fichier data.php crée une base sqllite avec tous les auteurs de ton SPIP
Les autres fichiers sont des shell
Documentation ici : webshell免杀-提升兼容性 - 先知社区 (il faut le traduire depuis le chinois simplifié)
Bref, tu es victime de la faille corrigée par SPIP 3.2.18 
Autrement dit, il faut que je demande à tous mes auteurs de modifier leurs mots de passe ?
Très probablement (même si les mots de passes sont encryptés par SPIP de manière non réversible).
Devrais-je retrouver ce fichier généré de base sqlite dans mes fichiers, dans config/bases/ ?
Car dans ce dossier, je n’ai rien retrouvé…
Oui et non : il peut très bien avoir été généré, récupéré et effacé
Concrètement, cela permettrait des accès usurpés auteurs ?
Au moins d’aller ensuite changer les emails des auteurs, puis de lancer la procédure d’oubli de mot de passe, pour récupérer un accès webmestre
Bon, si j’upgrade, puis demande à tous mes auteurs d’effectuer la procédure de changement de mot de passe, pourrais-je être tranquillisé après cela ?
Ou vaut-il mieux que je passe tout au lance-flamme avant ré-install ?
Oui et non : il faut aussi que tu vérifies tous les fichiers de l’hébergement à la recherche de quelque chose de pas normal.
Partout !
Bon, j’ai testé le fichier data.php pour voir, et j’obtiens une erreur 500 sur mon serveur.
Y a-t-il une chance pour que mon hébergeur m’ait protégé contre l’écriture de ce fichier de base, fin mars dernier ?
Dans mes logs, à ce timestamp, je trouve aussi :
« GET /data.php HTTP/1.1 » 500 546 « - »
Ok, dans le doute, je sors le lance-flamme.
Merci !
Bon, j’avais tout un tas de sites concernés en 3.2.x., qui pourtant n’avaient rien à voir les uns avec les autres.
Attaque automatisée et groupée le 23/03, entre 4h45 et 5h10.
J’ai retrouvé des fichiers spip.sqlite vide sur 2 d’entre eux.
Et j’ai passé le lance-flamme.
C’est à dire vérification des contenus de mes dossiers squelettes et IMG, vidange de tout le reste et mise à jour.
Bonjour,
A votre avis est-ce que la base de données peut-être utilisée malgré tout ? Pensez-vous quelle soit impactée ?
Merci
Il ne s’agit pas de « penser » mais de vérifier !
Techniquement, le hack permet de faire ce qu’on veut de la base puisqu’il permet de mettre le fichier php de son choix sur le serveur, donc de mettre un shell php qui permet ensuite de parcourir tous les fichiers et dossiers, de lire le contenu de config/connect.php et d’aller modifier la base de données.
Bonjour, merci pour cette réponse.
A priori je nai rien vu de modifié dans la base. Par contre j’ai verifié les fichiers : un fichier php à la racine du site, un dans le repertoire du plugin saisies et selon les versions dans ecrire et local.
Envoyé de mon Galaxy J6 Orange
-------- Message d’origine --------
De : RealET via Discuter de SPIP noreply@discuter.spip.net
Date : 13/05/2023 09:55 (GMT+01:00)
À : sbalin@orange.fr
Objet : [SPIP][Général] Fichiers suspects à la racine de mon site
Il ne s’agit pas de « penser » mais de vérifier !
Techniquement, le hack permet de faire ce qu’on veut de la base puisqu’il permet de mettre le fichier php de son choix sur le serveur, donc de mettre un shell php qui permet ensuite de parcourir tous les fichiers et dossiers, de lire le contenu de config/connect.php et d’aller modifier la base de données.
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
De façon à en apprendre un peu plus, pour la vérification de la base y a-t-il plus spécifiquement certaines tables à vérifier ?
Déjà vérifié auteurs ok, adresses mails ok, contenus ok, documents ok…
Merci pour votre aide 
Sur un site sur lequel je suis en train d’intervenir, j’ai trouvé un shell PHP :
tmp/pirates/z_ini_pirateConfig.php
C’est Triag File Manager version 1.1 : Tryag File Manager - Pastebin.com
Il n’est pas directement exécutable parce que le .htaccess de tmp bloque ça.
Mais je ne serais pas surpris que le spip.php rapporté comme modifié par d’autres dans ce forum pourrait permettre de le lancer avec le bon paramètre dans l’URL.