Fichiers étranges, normal ou piratage ?

Général
#1

UP ?

Bonjour,

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)
********************************************

spip@perline.org

#2

piratée !

#3

+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é.

#4

faut être ^pro pour comprendre :slight_smile:
la version plus simple ?

#5

Au hasard après une recherche dans le présent forum Alerte : vague de piratage de sites depuis le 23 avril : pas d’accès à /ecrire (version SPIP inférieures à 3.2.18, 4.1.8 et 4.2.1) - #7 par jeanmarie :slight_smile:

#6

Voir aussi Alerte : vague de piratage de sites depuis le 23 avril : pas d’accès à /ecrire (version SPIP inférieures à 3.2.18, 4.1.8 et 4.2.1) - #10 par jeanmarie

#7

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).

#8

Voir aussi sur ce blog: https://deep-dive.fr/acces-spip-impossible-et-attaque-en-regle/

#9

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.

#10

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.

–
nicod_

#11

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.

1 « J'aime »
#12

Ha oui j’ai vu ça sur un site aussi, une bonne base est de greper sur base64_decode avec rgrep base64_decode --exclude-dir=tmp.

#13

Je ne comprends pas ce que ça veut dire.

···

Natacha Courcelles via Discuter de SPIP a écrit le 10/06/2023 à 19:57 :

Natacha Courcelles
Juin 10

b_b:

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 :slight_smile:
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)
********************************************

spip@perline.org

#14

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 :

1 « J'aime »
#15

J’ai reporté certaines indications de nicod et b_b sur cette page qui listait divers conseils de Cerdic et Fil (ouioui) déjà : ConseilsSecurite

#16

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 ?

#17

C’est en cours de discussion ici #5632 - Bloquer php dans certains répertoires - spip - SPIP on GIT