Mon site est attaqué ! Que dois-je faire ?

Bonjour,

Tout est dans le titre malheureusement...

J'ai un énorme bloc de liens caché au niveau de mon footer qui crée des pages fantômes sur mon site. Il semble que cela provienne de la base de donnée, du moins en partie car je l'ai effacé puis rechargé à partir d'une ancienne base SQL mais cela ne semble pas suffisant... j'ai lu par ailleurs que du code pouvait se cacher un peu partout.

Que faire dans ce cas ? Comment procéder pour repartir sur une base saine ?

Merci à l'avance pour vos éventuelles réponses.
Modifié par Olivier C (09 Aug 2011 - 06:48)

Bonjour,

L'important est avant tout de pouvoir cibler d'où vient l'attaque.

Généralement (et très grosso-modo, je simplifie au max), ça peut venir de quelques lieux:

1- Changement apporté directement au code source (quelqu'un a probablement accès à tes fichiers FTP ou à ton compte admin)

2- D'une injection (généralement via PHP ou MySQL)

Dans ton cas, ça semble être à première vue être une injection. À partir de là, tu devras cibler la ligne qui injecte ce code. Par exemple, ce pourrait être :

echo $username;

Et si $username provient de ta BD, il peut en théorie contenir n'importe quoi. Un username, tout comme des balises html, voir une balise script, ou une balise <img> dont la source est un fichier .js externe, etc etc.

Dès que tu as trouvé sur quelle ligne l'injection se produit, tu n'as qu'à remonter ton code PHP jusqu'où ta variable est créé, ou jusqu'à l'endroit ou le contenu est ajouté à ta BD. À cet endroit, ce sera à toi de valider les données entrante afin de ne pas laisser de données corrompues passer ta sécurité.



Voilà pour ce qui est du principe de base, ensuite... Ça peut devenir très très très complexe. Si tu utilise un CMS mainstream, il est à jour ? Tu utilise des codes que tu as toi même écrit ?

Car bien franchement, les risques de piratages sont surtout situés sur des versions non mise à jour de CMS; un programmeur créé un robot qui crawl le web à la recherche de la faille qu'il a découvert. Peu de pirates vont perdre leur temps à essayer de trouver une faille sur un site dont le système n'est pas bien documenté. - Ils sont plutôt paresseux habituellement.

Merci beaucoup pour votre réponse Vaxilart,

Oui j'utilise un CMS, et comme il n'est pas bien difficile de déterminer lequel, quand celui-ci est très connu je peu vous avouez sans risque de confidentialité qu'il s'agit de Wordpress.

Vous première explication avec le code echo $username; a l'air très intéressante mais je vais avoir du mal à la mettre en œuvre car je suis un bleu du web. Pour le reste : oui, je suis régulier dans les mises à jours du CMS, quand au template je l'ai créé à partir de zéro.

Je me suis penché un moment la question des fichiers .js ou bibliothèques script récupérés à droite ou à gauche mais il me semble que les sources était fiables : jQuery et des fichiers de commandes éprouvés, sans soucis je pense. Par contre j'ai mis depuis peu de nouveaux scripts magnifiques mais... à vérifier. Ceux-ci on pourtant été récupérés (comme il est demandé de l'indiquer dans le code source) sur l'excellent site dhteumeuleu.

Le plus inquiétant je trouve est qu'il n'y avait pas que du code : des images étaient hébergées sur mon site, le code générant de fausses pages, ces images étaient affichées dans une "pseudo colonne gauche" à partir du fichier WP des contenus. La création de ces pages pouvait donc générer un faux référencement à ce qu'il me semble, c'est pourquoi je suis intervenu sans attendre.

Pour l'instant j'ai tout effacé puis tout rechargé. Merci aux sauvegardes récentes ! Espérons qu'elles ne soient pas vérolées elles aussi... Je viens de changer tous les mots de passe (connexion à l'admin du site, MySQL, FTP).
Modifié par Olivier C (24 Jul 2011 - 14:39)

Bonjour,

il ne faut PAS enregistrer les mots de passe dans Filezilla si c'est ce que tu utilises pour les transferts FTP. Et scanner + nettoyer ton PC avec Avast ou Antivir, MBAM, Ccleaner et ... si tu utilises Windows.

Reste, en plus de ce dont a parlé Vaxilart, l'hébergeur : d'autres clients se sont-ils plaints dernièrement d'un problème similaire ?

Bonjour Felipe,

J'ai un Mac, ce n'est pas une raison pour se croire à l'abrit mais je me dis que ça limite un peu la casse quand même...

Je ferais attention à l'avenir avec le FTP. J'ai déjà entendu ce problème à propos de Filzilla : comment les personnes malveillantes s'y prennent-elles pour récupérer ces mots de passe ? D'autre part : existe t'il une alternative plus sécurisante que Filezilla ? C'est un problème car je m'en sert énormément, s'il faut se logger à chaque fois c'est galère...

J'ai remis en place un site "propre" je pense (sauf un message d'erreur dont je ne sais que faire), mais il reste effectivement le plus important : comprendre d'où viens l'attaque.

Et sur ce plan là je crois que je ne suis pas doué pour trouver... j'irai voir les forums (OVH).
Modifié par Olivier C (24 Jul 2011 - 16:20)

Bonjour à toutes et à tous,

je ne connais pas grand chose en site internet cher un hébergeur.

Mais je suppose que si tu place un fichier .htpasswd, ne faut-il pas le mettre dans un répertoire dont l'accès est réservé uniquement à ton usage via un mot de passe ?

De même, ne faut-il pas crypter ton fichier des mots de passes ?

Si tu utilises une base de données pour stocker le $userid, ne faut-il pas utiliser les expressions régulières pour s'assurer que l'on y place bien que des lettres et des chiffres ? C'est à dire ce à quoi tu t'attends à trouver !

De même, si le problème vient de ta base de données, ne devrais-tu pas faire un "scan" ou si tu préfères une analyse de tous les champs pour trouver l'anomalie ?

Je sais que cela fait beaucoup de travail, mais je pense que c'est un minimum pour éviter des intrusions.

Qu'en pensez vous ?

@+

Artemus24 a écrit :

Qu'en pensez vous ?

Artemus24 a écrit :

Mais je suppose que si tu place un fichier .htpasswd, ne faut-il pas le mettre dans un répertoire dont l'accès est réservé uniquement à ton usage via un mot de passe ?

WordPress n'utilise pas de fichier .htpasswd pour l’authentification des utilisateurs.

Artemus24 a écrit :

De même, ne faut-il pas crypter ton fichier des mots de passes ?

"crypter" ce mot n’existe pas : on dit chiffrer quand on parle de cryptographie numérique.

Le chiffrement des mots de passe dans le fichier .htpasswd dépend de la configuration du système.

Artemus24 a écrit :

Si tu utilises une base de données pour stocker le $userid, ne faut-il pas utiliser les expressions régulières pour s'assurer que l'on y place bien que des lettres et des chiffres ? C'est à dire ce à quoi tu t'attends à trouver !

Dans WordPress l'id de l'utilisateur est stocké dans la base de donnée comme un entier donc ce champ ne peut pas contenir autre chose que des chiffres. Il faut bien entendu vérifier les données lors de l'insertion en base pour éviter les injections et erreurs mais dans le cas de l'ID de l'utilisateur il n'est pas inséré mais calculé par MySQL.
Modifié par jb_gfx (24 Jul 2011 - 19:05)

[Message devenu inutile, peut désormais être supprimé par la modération]
Modifié par Olivier C (09 Aug 2011 - 15:47)

Normalement tu regardes les logs du serveur, tu regardes quelle est l'IP qui a accédée en premier à un fichier vérolé puis tu recherches cette IP dans les logs pour voir quels fichiers elle a consulté avant ce qui te permet de retracer l'origine de la faille.

Mais la faille peut aussi venir du serveur et/ou d'un autre site hébergé sur le même serveur que toi (c'est très courant).

[Message devenu inutile, peut désormais être supprimé par la modération]
Modifié par Olivier C (09 Aug 2011 - 15:48)

Mince ! Je n'ai apparement pas éradiqué le virus. Google m'a avertit : j'ai une page pirate qui reproduit mon index, et je ne vois pas comment la supprimer. Le problème c'est que je pars en voyage demain... Si entre temps vous avez des suggestions à me faire n'hésitez pas à les poster ici, je vous en serais reconnaissant.

Voici la page pirate qui reproduit mon index :

-http://christus-web.com/?ebb=santa-rosa-beach-florida-pictures-march

Je ne vous demande pas d'aller sur cette page, mais si vous avez une idée de ce type de liens qui commence par "?ebb".

Bien à vous

Edit : Laurie-Anne : bien vu pour la neutralisation du lien.
Modifié par Olivier C (09 Aug 2011 - 12:56)

[Message devenu inutile, peut désormais être supprimé par la modération]
Modifié par Olivier C (09 Aug 2011 - 15:46)

Bon, je crois que j'ai trouvé le pot aux roses : en fait j'avais bien éradiqué le virus la première fois...

Seulement google a conservé les liens en mémoire et m'avertit d'un duplicat content par "cloaking". Seulement voilà, ces pages n'existent pas, ou plutôt elles n'existent plus : il s'agit tout simplement de données inscrites à la suite du permalien de mon nom de domaine qui était à l'origine une page pirate. Mais maintenant ces données sont toujours interprétées comme des pages car sous WordPress après un slash (/) on peut mettre un point virgule (?) pour interpréter une page, ce qui est ici le cas. En fait après une url de ce genre : "http://mondomaine.com/?" je peux mettre n'importe quoi, par défaut je resterais toujours sur ma page d'accueil, sauf si ce contenu indique réellement une page...

Ça craint : je pourrais envoyer à Google des pings en manuel avec des permaliens genre : http://mondomaine.com/?n-importe-quoi et Google va les lires comme des liens, en les repérant qui plus est comme "duplicate content" de la page index ! Comment pourrir le référencement d'un site web...

J'ai testé sur d'autres sites WP, ça marche aussi, en fait ça marche sur la plupart des sites web (ex : site du zéro) sauf sur Alsa ou l'on a un "The URI you submitted has disallowed characters".

Comment fait Alsacreation pour obtenir un tel résultat ? Un truc à rajouter dans le .htaccess ? Bref comment rediriger ou supprimer les pages "fantômes" trouvées par Google ?
Modifié par Olivier C (09 Aug 2011 - 15:45)

Bonjour,

N'y aurait-il pas un rapport avec ça ? -http://web.developpez.com/actu/35890/Des-milliers-de-blogs-WordPress-utilises-pour-infecter-Google-Images-les-images-referencees-redirigent-vers-des-serveurs-malveillants/

C'est bon : après une deuxième validation sous "outils pour les webmaster" la page index de mon website n'est plus référencée par Google avec le qualificatif de "site peut-être piraté".

Par contre Belkira vous avez suscité mon intérêt : votre message confirmerait la faille de sécurité que j'ai cru percevoir (même si à mon niveau, proche de 0, c'est un peu abusé d'avoir une telle prétention !).
Modifié par Olivier C (09 Aug 2011 - 16:27)