[Spip] Spip 2.0 : vulnérabilité et hack
webmaster spip
J'ai un problème sur un site qui se fait hacké, vers un site sur des petites pilules bleues. C'est problématique parce que le site est bien référencé, et que du coup on est affiché avec ça.
J'avais une version 1.9.2 qui s'est faite hackée sur plusieurs fichiers : ajout de codes dans les pages, ajouts de fichiers, etc. à la racine, dnas le fichier ecrire, dans squelettes, etc.
Bref, je suis passée à la version 2.0.10, la dernière, le seul plugin que j'ai est le couteau suisse.
J'ai gardé la même base de données forcément.
Depuis j'ai constamment de nouveau des hacks, sur des fichiers, avec de l'ajout de codes, etc. et de redirection de ma page principale vers leurs sites pharmaceutiques.
qu'est-ce que je peux faire sur le serveur, sur le spip, etc. pour éviter ces attaques ?
Quels sont également les conseils en terme de sécurité sur la dernière version quand on installe un spip ?
En vous remerciant, c'est assez urgent,
webmaster spip
ALors voir avec les admin du dit serveur pour qu'ils renforcent la securité du serveur, je crois savoir que les linuxiens ont l'avantage d'avoir des tas d'outils pour faire cela,
En attendant je ne sais ci cela peut servir, mais je changerais dans un premier temps l'ensemble des mots de passe à la fois sur le site mais aussi ftp serveur, ...
Regarder aussi du coté des log pour essayer de pister l'intrus, de voir par Où il passeLe 28 février 2010 10:22, webmaster spip <webmast...@gmail.com> a écrit :
L'hébergeur c'est nous (enfin pas moi, j'y connais pas grand chose en gestion de serveur, mais les responsables des serveurs dans notre boite). Le serveur est du LAMP.
Changer de serveur et refaire le site serait une solution, mais extrême, je ne peux pas forcément me le permettre pour des raisons de référencement, de liens, de temps à y passer (il y a plus de 500 pages), etc.
Donc s'il y a une solution...Le 28 février 2010 10:15, Eric Boutigny <e.bou...@gmail.com> a écrit :je suppose que vous avez signalé cela à l'hébergeur ... ça cela laisse à supposer qu'il y a des trous de securité sur ses systèmes, et que vous n'êtes surement pas le seul à avoir ce soucis.
La soluce brutale serait de changer d'hébergeur
_______________________________________________
liste spip
sp...@rezo.net - désabonnement : envoyer un mail à spip...@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
http://archives.rezo.net/spip.mbox/
Documentation de SPIP : http://www.spip.net/
Irc : de l'aide à toute heure : http://spip.net/irc
--
Eric Boutigny
06 32 99 82 64
--
Eric Boutigny
06 32 99 82 64
Eric Le Meur
L'hébergeur c'est nous (enfin pas moi, j'y connais pas grand chose en gestion de serveur, mais les responsables des serveurs dans notre boite). Le serveur est du LAMP.
Changer de serveur et refaire le site serait une solution, mais extrême, je ne peux pas forcément me le permettre pour des raisons de référencement, de liens, de temps à y passer (il y a plus de 500 pages), etc.
Donc s'il y a une solution...
Eric LM
webmaster spip
si je récupère une sauvegarde de la bdd et je la transfère sur un autre serveur, j'ai effectivement toutes mes pages qui devraient revenir, mais avec l'rul rewriting l'expérience de déplacement de site m'a déjà montré qu'il y en avait pas mal qui avaient sautées. De plus si je récupère la bdd et que celle-ci est comrompue, je déplace le problème avec.
Comment savoir si la bdd est corrompue (rien ne ressemble plus à une entrée qu'une autre entrée dans une base !, ok je ne suis pas spécialiste de la bdd)
Par ailleurs pour la comparaison de fichiers, je l'ai faite hier, supprimé les fichiers qui me semblaient corrompus, remplacés par des bons, et ce matin, rebelote, de nouveau un ajout de code dans le index.php
Je ne peux pas la faire à tout moment...
merci pour vos réponses en tout cas
Bertrand Marne
Je ne suis pas un grand connaisseur de la sécurité des serveurs...
Le 28 février 2010 11:03, webmaster spip <webmast...@gmail.com> a écrit :
> Par ailleurs pour la comparaison de fichiers, je l'ai faite hier, supprimé
> les fichiers qui me semblaient corrompus, remplacés par des bons, et ce
> matin, rebelote, de nouveau un ajout de code dans le index.php
> Je ne peux pas la faire à tout moment...
Mais ce que tu décris dans tes emails ressemble vraiment à un problème
d'intrusion au niveau du serveur et non de Spip.
Je pense qu'il faut que tu reprennes tout à zéro:
- Dévérolé et faire dévérolé tous les ordis des gens qui ont un accès
FTP et qui sont admin Spip (à mon avis c'est là que se trouve ta
faille).
- dévérolé le serveur (une réinstallation d'une distrib' fraîche et à
jour ? Ou au moins le passage au détecteur de rootkits &co en Live
CD).
- réinstaller un spip tout neuf dans lequel tu importes ton ancienne
base de données (peut-être que la base est vérolée, mais je ne suis
pas sûr que ce puisse être une source de nouvelles intrusions)
- résintallation des squelettes après les avoir soigneusement vérifiés
(pour éliminer les éventuels hacks).
- tests abondants sur le contenu de la base notamment.
Je pense que le souci vient vraiment d'un des ordinateurs des gens qui
ont un accès en FTP étant donné que tu as changé les mots de passe,
réinstallé Spip et que les hacks reviennent très vite.
Bon courage !
--
Bertrand
Philippe Vayssière
je te renvoie à ce que j'avais détaillé sur le forum Spip :
http://forum.spip.org/fr_216523.html sous le pseudo Felipe
Mon second message te concerne aussi puisque tu as été RÉinfecté : ça
continuera tant que tu n'auras pas changé ton mot de passe FTP. Et
puisque le pirate a eu accès au fichier config/connect.php ça craint
aussi du côté du mot de passe de la BDD.
Côté antivirus, Avast n'avait pas été performant du tout il y a 6 mois
et Antivir si, du moins pour l'attaque que nous avions eu (des iframe
vers des sites russes/ukrainiens/indiens).
Je complète ci-dessous :
Le 28/02/2010 11:03, webmaster spip a écrit :
> Oui effectivement, mais ce n'est pas tant le nom de domaine qui pose
> problème, mais plutôt les urls des pages internes : si je récupère
> une sauvegarde de la bdd et je la transfère sur un autre serveur,
> j'ai effectivement toutes mes pages qui devraient revenir, mais avec
> l'rul rewriting l'expérience de déplacement de site m'a déjà montré
> qu'il y en avait pas mal qui avaient sautées. De plus si je récupère
> la bdd et que celle-ci est comrompue, je déplace le problème avec.
Si tu récupères (je crois) la table spip_urls et le fichier .htaccess ,
je vois pas comment tes URLs pourraient être modifiées.
Mais pour commencer, je vois pas non plus à quoi ça sert de déménager
ton site ...
> Comment savoir si la bdd est corrompue (rien ne ressemble plus à une
> entrée qu'une autre entrée dans une base !, ok je ne suis pas
> spécialiste de la bdd)
Rechercher les mots iframe, script, eval et poker/pilule bleue/p17u7e
bl3u3 (enfin les fautes d'orthographe volontaires que tu as pu constater
sur ton site) et qui n'ont rien à faire dans la BDD.
Dans les fichiers de SPIP, il y a des iframes (surtout avec FCKEditor si
tu l'as installé) mais je crois aucun avec l'instruction visibility:
hidden; Si tu sais rechercher avec une expression régulière tu peux
rechercher un masque, les pirates changent l'intitulé des liens mais pas
de méthode.
Ça c'est pour des attaques relativement décelables mais j'en ai vu
passer une dernièrement où les liens étaient cryptés, d'où la recherche
d'eval() ci-dessus. Là c'est plus long de s'assurer que tu as vraiment
tout bien nettoyé !
Si tu as un moyen de rajouter une tâche cron (il faut être admin de son
serveur ou le connaître) et que tu connais le type d'attaque dont tu as
été victime (exemple pour moi: <iframe src="blabla" style="visibility:
hidden;" blabla), tu peux créer un script PHP qui compte le nombre
d'occurences de ce masque et qui envoie un mail si le serveur est
réinfecté. Je sais qu'il y a 13 fois ce masque sur mon site, notamment
dans FCKEditor, j'ai vérifié à la main les 13 occurences et elles sont
normales et attendues mais le jour où une 14ème occurence apparait, tout
Alsacreations.fr sera prévenu par mail avec renvoi d'un mail toutes les
5 minutes jusqu'à ce que dew ou moi-même ayons réglé le problème ... ou
que le client nous ait achevé ^^
Si tu n'as pas moyen d'avoir un cron, tu peux quand même créer le script
mais il te faudra le lancer manuellement toutes les N heures (au moins
une fois par jour quoi) et vérifier de tes yeux qu'il donne le même
résultat que la veille.
>
> Par ailleurs pour la comparaison de fichiers, je l'ai faite hier,
> supprimé les fichiers qui me semblaient corrompus, remplacés par des
> bons, et ce matin, rebelote, de nouveau un ajout de code dans le
> index.php Je ne peux pas la faire à tout moment...
Voir changement du mot de passe FTP ci-dessus.
>
> merci pour vos réponses en tout cas
>
Ph. Vayssière
--
expert Accessiweb en évaluation et intégrateur XHTML/CSS
www.alsacreations.fr
Expertises, Solutions et Créations pour le Web
5 rue des Couples 67000 Strasbourg - France
Tél. : +33 (0)9 54 96 50 50