Site SPIP hacké OMTOGEL

Général
#1

Bonjour à tous,

Hier, un site tournant sur spip 4.2.11 a été hacké. " OMTOGEL ".

Deux fichiers ont été placés à la racine du serveur, index.php et app.php
J’ai également identifié un fichier index.php placé dans /lib, contenant Obfuscated by YAK Pro - Php Obfuscator 2.0.14 | GitHub: GitHub - pk-fr/yakpro-po: YAK Pro - Php Obfuscator

Après suppression de ces fichiers, et mise à jour vers la dernière version 4.3.2 le site est de nouveau fonctionnel et j’espère que la faille est corrigée.

Des pistes pour vérifier s’il y a d’autres atteintes ?

#2

4.2.11 était en effet avec fail.

Pour une vérification plus approfondi, tu peux utiliser spip-contrib-outils / spip_cleaner · GitLab de @azerttyu

#3

Merci pour la piste.

Site en vrac, le fichier index.php a de nouveau été remplacé.
J’ai trouvé à la racine de l’hébergement, dans un rep .config, un fichier détecté par mon AV comme étant Hack Tool Linux GsNetcat.

#4

probablement qu’ils ont mis en place un fichier qui reinstall automatiquement les fichiers vérolés…

#5

Et ce fichier vérolé peut avoir été placé au-dessus de ton site si ils ont réussi à passer …
N’empêche, pour t’assurer que ton site est clean, plutôt que d’ouvrir tes dossiers un à un, tu réinstalles un SPIP propre (le plus simple est d’utiliser spip_loader.php qui nettoies aussi ce qui ne va pas) et tu vérifies ces répertoires avant de les basculer dedans.

  • IMG
  • config
  • plugins
  • squelettes

Et tu ne perdra pas les données de ton site puisque le fichier de connexion dans config/connect.php est conservé. Tes données de site étant dans cette base Mysql.

Après, merci de suivre ces conseils scrupuleusement, ça devient difficile d’aider. En ce qui me concerne j’ai décidé que le SAD se ferme automatiquement quand il s’agit de personnes qui ne prennent pas le temps de lire et ne suivent pas les conseils qu’on leur apporte … Le bénévolat dans ces cas là, niet.

#6

Une petite recherche indique que c’est un virus qui touche Ubuntu 20.04 - J’ai l’impression que ce n’est pas ton site qui est à l’origine de ce piratage. Est-ce que c’est toi qui gère l’hébergement ?

#7

Je pensais avoir viré les fichiers vérolés, mais ce matin index.php a de nouveau été remplacé…

Tout réinstaller, oui c’est ce que je ferai si je n’arrive pas autrement. Mais ré-installer et reconfigurer tous les plugins…

J’ai déjà utilisé spip_loader pour la mise à niveau.

Le site est hébergé par ovh, je leur ai indiqué le problème, à voir.

#8

Il ne s’agit que de réinstaller les plugins, la configuration est déjà dans la base.

#9

larc via Discuter de SPIP a écrit :

[larc] larc https://discuter.spip.net/u/larc
Octobre 7

Je pensais avoir viré les fichiers vérolés, mais ce matin index.php a de
nouveau été remplacé…

Tout réinstaller, oui c’est ce que je ferai si je n’arrive pas
autrement. Mais ré-installer et reconfigurer tous les plugins…

J’ai déjà utilisé spip_loader pour la mise à niveau.

Le site est hébergé par ovh, je leur ai indiqué le problème, à voir.

Bonjour,

Ces véroles installent un cron pour l'utilisateur en question. Donc à

vérifier aussi.

Bien cordialement,

JB
#10

Pas de taches cron sur l’hébergement.
Rien d’anormal sur celles de Spip.

C’est étonnant, le code injecté dans index.php n’est pas le même aujourd’hui.

#11

C’est qu’il reste des traces quelque part. Regarde dans les dossiers non mis à jour (comme IMG).

#12

Tu es bien sûr qu’il n’y a pas du tout de crontab ?

Vérifier aussi les contenus de /tmp, /var/tmp et /dev/shm dans lesquels Apache peut écrire, qui sont souvent ciblés pour y déposer des fichiers malveillants.

#13

Hello

çà ressemble à la vague d’attaque post bigup. Correction arrivant avec la 4.2.16 si ma mémoire est bonne.
spip-contrib-outils / spip_cleaner · GitLab s’occupe d’identifier les pattern type remontée par la communauté au fil des hacks et nettoyage réalisé.
Il s’occupe aussi de contrôler les crontab

Je complète avec amwscan qui détectera des compléments intéressants.

Quand il est possible il est préférable de mettre en place une instance vierge et de réimporter la base de données.

#14

Bonjour,
Merci pour vos conseils.

J’ai trouvé et supprimé hier deux fichiers Gs Netcat, dans des rep .config et .softaculous. à la racine de l’heberg.
Depuis, pas de suppression ni d’injection de code.

Pour spip_cleaner, je n’ai pas d’accès console sur OVH.

#15

Bonjour
j’ai eu le même problème hier avec les même fichier que Larc. Initialement, j’avais la même version que lui
J’ai effacé entièrement l’hébergement et installé la version d’août 2024. Ce soir site à nouveau piraté :frowning:
il n’y avait plus qu’un index.php avec une redirection vers un site web (le même que hier).
J’ai à nouveau tout effacé et installé la version 4.3 de ce jour.
A voir…
bonne soirée
Claude

#16

Bonjour,
Où place-t-on spip_cleaner ?
Où apparaissent les résultats ?
Merci !

#17

larc via Discuter de SPIP a écrit :

[larc] larc https://discuter.spip.net/u/larc
Octobre 7

Pas de taches cron sur l’hébergement.
Rien d’anormal sur celles de Spip.

C’est étonnant, le code injecté dans index.php n’est pas le même
aujourd’hui.

Attention, sous Unix, le cron de l’utilisateur apache, mais pas ce qui
est dans /etc/cron.d et consorts.

#18

Bonjour

C’est un script à télécharger sur son serveur et ensuite commande à lancer depuis bash.

Km

1 « J'aime »
#19

Bonjour et merci Km,

J’imagine que le script est à placer à la racine.
Par contre, désolé d’être ignare mais lancer un script depuis bash sous Spip, cela dépasse mon domaine de compétence.

Gui.

#20

Il faut un serveur dédié pour avoir la mian sur l’ajout de scripts, les hébergements mutualisés ne le permettent généralement pas.