Attaque d'ampleur dans la nuit du 23/03 + autres vagues ?

Bonjour à tous,

Il semblerait donc que les 2 derniers mois aient connu au moins 2 vagues d’attaques massives et automatisées contre des sites tournant sous SPIP et non encore à jour avec la MAJ parue fin février 2023.

1ère vague connue : nuit du 23 mars. L’outil d’attaque est passé par l’intégralité de mes SPIP entre 4h48 et 5h08. Sites chez des hébergeurs différents. Versions de SPIP différentes.
Il semblerait donc que le « bot » ait interrogé une liste préalablement établie de sites SPIP. C’était bien ciblé.
Symptômes : fichiers php (noms aléatoires) retrouvés à la racine + fichier data.php
But apparent de la tentative : les fichiers php déposés par injection essaient d’interroger la base et de créer une liste des auteurs + mot de passe du site, dans un fichier sqlite créé dans config/bases/
Bilan : la tentative est-elle fructueuse ou pas ? Aucune idée. Pour certains sites, j’ai trouvés des fichiers sqlite vides. Je n’ai jamais trouvé de fichiers avec un contenu exploitable. Qu’en est-il pour vous ?
Que faire ? Les experts répondront plus en détails, mais personnellement, j’ai mis à jour Plugins + SPIP, puis j’ai fait une sauvegarde de base, sauvegardé mes dossiers IMG et squelettes, vérifié que ceux-ci ne contenaient pas de fichiers suspects créés à la même date. Puis j’ai effacé toute mon installation via FTP, avant de ré-installer à partir de zéro, puis de remettre en place mes sauvegardes sur la nouvelle version.
Seule façon de garantir que les pirates n’avaient pas écrit de fichiers php ailleurs, leur permettant d’avoir à nouveau un accès.
J’ai également demandé à tous mes auteurs (sur les différents sites) de changer leur mot de passe (au cas où l’export des auteurs aurait été fructueuse), ou plutôt, j’en ai généré un pour eux (grâce au bouton dédié), en les prévenant.

2. Deuxième vague début mai : Je n’ai pas été directement concerné par celle-ci, mais d’après ce que j’ai pu lire sur ce forum, cela se manifeste par une impossibilité d’accès au backoffice, due elle-même à une modification des fichiers htaccess et spip.php à la racine.

En 15 ans d’utilisation de SPIP, je n’ai rien connu de cette ampleur.

Existe-t-il à ce stade un article documenté sur ces attaques, leurs succès ?
Un article abordant également peut-être les mesures à prendre.
Évidemment, il aurait mieux valu mettre à jour à temps, mais nous n’en sommes hélas plus là (cela dit, la piqure de rappel a fonctionné pour moi, et il est clair que mes notifications pour les futures MàJ SPIP sont maintenant actives sur plusieurs canaux, et je n’attendrai plus plusieurs semaines avant de les lancer).
Aujourd’hui, il vaudrait peut-être mieux chercher à aider les victimes de ces attaques, aux compétences techniques souvent diverses, plutôt que de leur rappeler qu’elles ont tardé sur leur mise à jour.

Je peux fournir des fichiers + logs aux experts pour la 1ère vague évoquée ci-dessus.
Merci de m’avoir lu.

1 « J'aime »

Je confirme, du jamais vu. J’ai eu IONOS qui a reçu plusieurs appels sur ce sujet.
Première étape, comme mentionné, plus d’accès au back-office
J’ai corrigé, fait les mises à jour demandées.
Seconde étape, plus aucun accès, erreur 500, impossible de se connecter en SFTP, ou SSH.

Ionos a bloqué les process, le temps que je déplace TOUS les fichiers.
Je tente une restauration sur un espace vierge et une mise à jour vers la dernière version de SPIP 4.2.2 !

Je viens de trouver la réponse : Vulnérabilité dans SPIP – CERT-FR
Objet: Vulnérabilité dans SPIP

GESTION DU DOCUMENT

Référence CERTFR-2023-AVI-0213
Titre Vulnérabilité dans SPIP
Date de la première version 10 mars 2023
Date de la dernière version 13 mars 2023
1 « J'aime »

Le 13/05/2023 à 18:13, RK via Discuter de SPIP a écrit :

Aujourd’hui, il vaudrait peut-être mieux chercher à aider les victimes de ces attaques, aux compétences techniques souvent diverses, plutôt que de leur rappeler qu’elles ont tardé sur leur mise à jour.

Je trouve ça plutôt bien formulé.

Cependant comme l’ont rappelé james ou marcimat je ne sais plus, dans de précédentes réponses, la petite équipe a déjà donné beaucoup de temps, a corrigé les failles toujours super rapidement, a publié des versions et des articles pour prévenir critiquement de mettre à jour etc. Et a aussi aidé de nombreuses personnes après coup dans les forums sur comment vérifier, comment nettoyer au mieux.

Je pense donc qu’il ne faut pas avoir peur : les sites de la commu ont toujours été libre d’inscription. Ya donc comme un appel : si quelqu’un se sent de démarrer un brouillon d’article détaillé, expliquant déjà le fait même qu’il y a eu des vagues d’attaques massives, et qui ensuite liste ce qu’il faut faire, puis conclu en rappelant qu’il faut mettre à jour à temps… Gogo sur spip-blog, inscription, rédacteur, proposition d’un article.

Je peux me tromper mais je pense que les core devs à même de vérifier la justesse du brouillon seront contents de « juste » avoir à relire et valider, plutôt qu’eux mêmes trouver le temps de rédiger encore un article entier à zéro.


RastaPopoulos

1 « J'aime »

Est-ce qu’il ne serait pas profitable, dans le cadre de cette communication, d’ouvrir publiquement les tickets de sécurité quelques semaines après la release de sécurité.

Pourquoi ?

Parce que ça aurait 2 effets possibles :

  • faire prendre conscience de la gravité
  • apprendre aux non core dev à mieux sécuriser leur code eux aussi

Qu’en dit la @spip-team-me ?

Après ces attaques j’ai essayer de m’inscrire sur plusieurs canaux officielles spip pour m’assurer de ne plus jamais manquer d’alerte de sécurité, tout ca pour me rendre compte que a part les listes officielles spip ne communique pas beaucoup;

pas de compte twitter officiel,

pas de compte facebook officiel,

pas de page youtube officielle.

et les recherches SEO sur moteur de recherche reviennent souvent du contenu 2013 en première page.

Et le pire de tous , le flux RSS sur contrib.spip.net retourne aussi un contenu rss de la version anglaise du site avec du contenu d’il y a plusieurs années.

On Tue, May 23, 2023 at 9:29 PM RealET via Discuter de SPIP <noreply@discuter.spip.net> wrote:

RealET
Mai 23

Est-ce qu’il ne serait pas profitable, dans le cadre de cette communication, d’ouvrir publiquement les tickets de sécurité quelques semaines après la release de sécurité.

Pourquoi ?

Parce que ça aurait 2 effets possibles :

  • faire prendre conscience de la gravité
  • apprendre aux non core dev à mieux sécuriser leur code eux aussi

Qu’en dit la @spip-team-me ?


Voir le sujet ou répondre à ce courriel pour répondre.

Pour vous désabonner de ces courriels, cliquez ici.

Et le canal principal d’info : https://blog.spip.net/ avec son flux RSS aussi

Merci je m’abonne. Et aussi au flux RSS de blog.spip.net

On Tue, May 23, 2023 at 9:53 PM RealET via Discuter de SPIP <noreply@discuter.spip.net> wrote:

RealET
Mai 23

Voir le sujet ou répondre à ce courriel pour répondre.

Pour vous désabonner de ces courriels, cliquez ici.

1 « J'aime »

Non. Pourquoi ? Parce que techniquement ça implique de les déplacer d’un dépôt privé vers le dépôt public, et donc on perdrait les références aux tickets dans les commits qui les mentionnent. Mais surtout, cela permettrait au script kiddies d’avoir sans aucun effort accès aux vecteurs qui permettent d’exploiter les failles avant même qu’elles ne soient intégrées dans les outils qui permettent de les exploiter en masse, bref un grand mal pour un petit bien qui ne sera lu que par quelques personnes.

Sur l’objection technique, je comprends. Dommage que ça ne puisse pas être un simple statut « public ».

Sur les scripts kiddies, j’y avais pensé, et c’est pour cela que j’ai parlé de « quelques semaines ».

Très concrètement, sur la faille actuelle, j’ai l’impression qu’elle n’est corrigée que par l’écran de sécurité.
Mais sans accès au ticket en question, c’est difficile à vérifier.

Et pourtant, c’est important pour savoir quoi répondre correctement à Ecran de sécurité même si site déjà mis à jour ?

Non, c’est aussi corrigé dans SPIP.
Le «problème» actuel de l’écran de sécu, c’est qu’il rend un autre service : la mitigation des bots.
On pense qu’il faut qu’on sépare ça en 2 : garder dans le core SPIP la mitigation des bots, mais virer tout le reste. Un SPIP (+ plugins) a jour ne devrait pas avoir besoin de ce fichier.

Bon, bin mise à jour 4.2.2 depuis 1 semaine et le site est à nouveau tombé erreur500, aucun accès SSH si SFTP !
Un peu ma claque de gérer ces attaques !

Est-ce que tu es sûr d’avoir supprimé tous les fichiers (scripts PHP shell) rajoutés par le hacker avant la mise à jour ?

Hello
Je suis reparti d’une ancienne sauvegarde mise à jour après transfert. Je pensais être tranquille.
Raté !

Je retente depuis un SPIP Vierge 4.2.2

Je viens de regarder SPIP-Contrib et je n’ai rien en anglais et que du récent…

Outre la réponse de @RealET
SPIP est une petite communauté autogérée, rappellons le. Et qui se méfie des grosses structures du GAFA (à raison d’ailleurs). Donc forcément ce n’est pas là que nous mettons notre énergie.

En analysant les logs j’ai vu mon erreur, je n’avais pas supprimé le dossier créé pour déplacer toutes les merdouilles.
C’est stable !
J’en ai fait un article pour ceux que ça intéresse : https://deep-dive.fr/acces-spip-impossible-et-attaque-en-regle/