Bon, c’est un article que j’aurais préféré ne pas devoir écrire mais…
Le 15 juillet en fin d’après midi, je me suis aperçu que le site avait été hacké. Comment ? J’étais en train de travailler sur un article dans l’éditeur WordPress et je vois des trucs se passer dans la colonne de gauche (menu principal)… Franchement je n’ai pas noté ce qui a attiré mon attention à ce moment là mais je vais faire un tour dans la rubrique Extensions et là surprise, TOUS mes plugins sont marqués : Désactivé suite à l’erreur : Cette extension ne dispose pas d’un en-tête valide. Pas d’entête valide ? je vais jeter un coup d’œil au tableau de bord et je reviens dans les extensions… Surprise, tout a disparu ! Plus d’extension, point de plugin.
Pour vérifier je fais un tour sur la page PiYou-PiMe qui affiche une carte avec le plugin wp-google-maps-pro. Effectivement il y a juste le shortcode au lieu de la carte. Arghhh
J’ouvre Filezilla et je me connecte au blog en FTP. La première chose qui me saute aux yeux c’est le fichier index.php qui fait 14Ko alors que d’habitude il fait 400 octets environ !
Bon… voyons ça : je descends le fichier sur mon disque et je l’ouvre avec notepad++ pour découvrir ceci au début du fichier :
…/…
Oula ça ressemble terriblement à du code obfusqué ! pas bon…
Une recherche rapide sur le début du code confirme cette (mauvaise) impression :
Je jette un coup d’oeil aux autres fichiers PHP du blog, enfin pas tous je fais un échantillonnage au travers des différents dossiers et effectivement TOUS comportent le code PHP de m… au début du fichier. D’où l’éjection des plugins.
Je mets dans les minutes qui suivent un avertissement sur la page Facebook du blog pour prévenir les lecteurs qui fréquentent cette page, afin qu’ils ne soient pas étonnés des perturbations à venir !
Ensuite vient le moment où on se posent des questions :
- Pourquoi mon blog ?
- Par où sont-ils entrés
- Quels dégâts ont-ils fait
- Quel est leur but ?
- …
La réception de quelques messages porteurs d’un avertissement en entête disant que le message provient sans doute d’un site piraté. Donc l’objectif serait selon moi la mise en place d’un serveur de SPAM utilisant mon hébergement… Mais je peux me tromper.
Que faire ?
Après lecture de quelques sites parlant de piratage, il apparait que la réinstallation à partir de sauvegardes est risquée car le hacker a pu introduire son fichier plusieurs jours (mois) avant de déclencher l’attaque.
Vérification faite (dans les sauvegardes), les fichiers php étaient déjà infectés la semaine précédente. La décision est donc de réinstaller « à blanc ».
Bon, ça va être l’occasion de tester les sauvegardes pour lesquelles je cotise chez web4all 😉 En général on ne sait qu’une sauvegarde fonctionne que quand on fait une restauration. Eh bien le moment vient d’arriver !
Certains correspondants m’ont déconseillé d’utiliser un CMS et de développer mon propre site web…
Pour avoir développé deux versions du site d’une ville, une en statique et une en dynamique (avec Base de Données et BackOffice) je ne voulais pas renouveler cette expérience qui est très chronophage en ce qui concerne le développement et détourne de l’objectif principal (ici le Raspberry Pi !). D’autre part n’étant pas un développeur de formation, je ne suis pas (du tout) certain que le code que je produis soit plus « costaud » que le code d’un WordPress par exemple… Faut savoir rester à sa place 😉
Un blog WordPress est constitué de plusieurs parties :
- Le programme et ses annexes (thèmes, plugins…)
- Les fichiers uploadés (images, pdf, zip…)
- La base de données (articles, commentaires…)
Avant de faire quoi que ce soit sur le blog : Opération récupération des données !
Les fichiers uploadés :
Si Filezilla permet de récupérer les fichiers présents sur le blog, j’ai opté pour la récupération d’une sauvegarde. D’une part ça permet de tester le fonctionnement, d’autre part je préfère récupérer des infos datant d’avant l’attaque… Même si les fichiers images ou pdf présentent peu de risques.
Connexion au manager chez web4all :
Dans le menu de gauche rubrique Sauvegarde > Sauvegarde de Fichiers
Apparait dans la partie droite la liste des sauvegardes disponibles (horaires sur 72h, journalières sur 15 jours, hebdomadaires sur 6 semaines et mensuelles sur 6 mois). Après choix de la sauvegarde à restaurer on passe à cet écran :
Il est alors possible de choisir une restauration complète ou sélective (20 dossiers ou fichiers). Dans mon cas seuls les fichiers uploadés m’intéressaient, c’est donc ce choix que j’ai fait. La restauration se fait sur le site web, dans un endroit choisi par l’utilisateur. J’ai choisi de restaurer dans un dossier « à part » que j’ai récupéré avec Filezilla. J’ai ainsi pu vérifier qu’il n’y avait pas de fichier php « baladeur » parmi ces fichiers.
La base de données :
Les bases de données sont sauvées sur ftp-bk-mysql.web4all.fr
J’ai utilisé le compte FTP sans restrictions que j’ai créé sur l’hébergement pour gérer les backups et j’ai pu récupérer les BDD de mes sites au format …sql.gz
Là aussi récupération de la BDD du blog (c’est celle qui fait 5,4Mo) en local et inspection pour voir si des choses « bizarres » y figurent.
Nettoyage du blog
Après la récupération des données et de la BDD vient le moment de « faire le ménage ». Connexion au blog en FTP avec Filezilla. Le blog se trouve dans un dossier /www/htdocs. c’est ce dossier qui fait l’objet du nettoyage. Tout sélectionner et appuyer sur la touche Supprimer !
Après un moment de patience (et de stress) on se retrouve avec un dossier vide. glups 🙁
Effectivement une tentative de connexion au blog renvoie un gros message d’erreur.
Deuxième étape, connexion avec PHPMyadmin sur https://pma.web4all.fr/
Les login et MDP sont ceux de l’utilisateur de la Base de Données.
Suppression de toutes les tables de la Base de Données.
Réinstallation de WordPress
Téléchargement de la dernière version de WordPress en français. Récupération de l’archive en local, dézippage et transfert dans le fichier /htdocs. c’est reparti !
La version WP 4.2.2. ne comporte plus le thème Twenty Twelve que j’utilise. Il faudra le remonter manuellement.
Installation de WordPress, renseignement des infos pour l’accès à la BDD.
Remise en place de la BDD récupérée et vérifiée avec PHPMyadmin :
Un clic sur importer, choisir le fichier sur le disque local et… c’est parti
A noter que mes tentatives d’envoi du fichier compressé en ZIP ont échoué et qu’il a fallu que j’envoie le format SQL (40Mo au lieu de 5Mo !) pour que ça fonctionne. A partir de là le blog commence à revivre et même si tout ne s’affiche pas encore correctement, on voit des choses…
Il va falloir ensuite remonter les fichiers uploadés (les images, vidéos, pdf…). Ce sera le plus long. Ah oui, elle existe bien la fracture numérique 😉 J’habite en ville à quelques Km du central téléphonique et j’ai une bande passante en upload… je vous dis même pas, vous prendriez peur! Elle est loin la fibre ?
Une fois tout le contenu remonté sur le blog, il reste à remonter les plugins, un par un. Je maintiens une liste des plugins, ce qui permet de remonter rapidement ceux-ci.
Après modif des clés de salage dans wp-config.php, j’ai ajouté
/** Désactive la fonctionnalité de
* modification des thèmes - Sécurité
*/
define('DISALLOW_FILE_EDIT', TRUE);
sur les conseils de raspbian france pour appliquer la mesure de sécurité préconisée par le codex WordPress :
- Avertissement de sécurité
- Par défaut, tout utilisateur qui se connecte avec des droits d’administrateur peut accéder aux éditeurs WordPress et ainsi modifier n’importe quel fichier du thème ou d’une extension sur votre site en temps réel.
- Pour lutter contre les accidents, les erreurs et même le piratage, vous pouvez désactiver la possibilité de modifier des fichiers dans le thème WordPress en ajoutant la directive DISALLOW_FILE_EDIT dans votre fichier wp-config.php.
Florian m’avait conseillé de mettre en place un firewall comme ninjafirewall (que je ne connaissais pas) :
Ce firewall nécessite la modif du fichier php.ini pour pouvoir intercepter tout ce qui arrive sur le site :
Avant ninjafirewall :
|
1 |
Attaquant > serveur HTTP > PHP > WordPress > Plugins |
Après installation de ninjafirewall :
|
1 |
Attaquant > serveur HTTP > PHP > NinjaFirewall > WordPress |
Chez web4all l’ajout d’un fichier php.ini à la racine n’est pas prise en compte et ne modifie pas le fonctionnement. Le firewall signale qu’il n’est pas installé 🙁 Avec l’option .user.ini en revanche, le firewall est bien activé (attendre quelques minutes car la présence du fichier est testée toutes les 5 minutes par défaut).
J’ai ensuite exploité un certain nombre de conseils/liens envoyés par les lecteurs du blog (que je remercie vivement)
- http://legissa.ovh/internet-se-proteger-des-pirates-et-hackers.html (Samdania)
- https://detectify.com/ (Amaury)
- http://security.stackexchange.com/questions/70579/is-this-a-backdoor (Florian)
- https://blog.sucuri.net/2014/09/conditional-malicious-iframe-targeting-wordpress-web-sites.html (Florian)
- https://addons.mozilla.org/fr/firefox/addon/sql-inject-me/ (Laurent)
- http://ninjafirewall.com/wordpress/overview.php (Florian)
- http://www.iceranking.com/wordpress-seo/guide-complet-pour-nettoyer-et-securiser-wordpress-apres-un-hacking/ (moi)
- http://blogmotion.fr/programmation/faille-wordpress-9722 (xhark de blogmotion)
Conclusion
Il aura fallu pratiquement 2 jours pour remettre le blog en service normal. Tout a été restitué, ce qui permet de conserver l’historique, vos commentaires et les … 542 articles qu’il aurait été dommage de perdre !
Merci amis lecteurs du blog pour votre patience et votre soutien sur la page facebook (il y a eu 1000 lectures sur les infos que j’y mettais au fur et à mesure de l’avancement des travaux). D’ailleurs si vous avez des problèmes d’accès au blog, utilisez la page facebook pour le signaler 😉
Cet article pourra sans doute servir à d’autres, et pour moi ce sera un aide mémoire pour la prochaine fois (vous voyez je suis optimiste…)
« Seul un ordinateur éteint, enfermé dans un coffre-fort et enterré six pieds sous terre dans un endroit tenu secret peut être considéré comme sécurisé, et encore. », assure Bruce Schneier, expert en sécurité informatique.
Pour quelqu’un qui n’est pas « un développeur de formation » chapeau.
Merci pour les infos.
pas développeur mais vieux technicien 😉
Donc en résumé tu t’es pris un Shell Backdoor via un plugin WordPress troué… ça fait jamais plaisir 🙁 les plugins sont la première source de faille de sécurité des CMS/Blogs.
Sinon j’utilise aussi WordPress File Monitor Plus qui vérifie la liste des fichiers et m’envoi un rapport.
bonjour
oui c’est ça !
ninja firewall fait cette verif aussi et envoie un mail avec un fichier texte contenant le nom des fichiers modifiés :
File integrity monitoring (File Check) to scan your website hourly, twicedaily or daily
Il me signale par exemple quand j ‘ai uploadé une image.
Chaque connexion à l’admin est aussi signalée…
cordialement
François
Bonjour et bravo pour avoir remis le tout en état. Avez vous des logs/journaux fournis par votre hébergeur ? Ou avez vous ou les contacter pour leur demander s’ils ont vu du trafic suspicieux ? Chez ovh on a ça a dispo quand on veut ça peut être pratique pour renter de comprendre par où ils sont passés.
Bon courage.
je vais voir…
web4all est chez OVH
merci!
cordialement
François
Bonjour,
non non Web4all n’est PAS chez OVH 😉
Depuis 2 ans nous sommes autonomes 😉
https://www.web4all.fr/technologies-reseaux.html
oups ! désolé je retarde alors !
Euh non, plus depuis 2013…
voilà comme ça c’est clair !
je suis resté sur une « vieille » info !
cordialement
François
Il m’est arrivé aussi de me faire hacker un des sites hebergés sur mon serveur.
La méthode d’entrée a été simple et discrète : le brute-force par FTP.
En effet, après avoir analysé les logs de mon serveur, je me suis rendu compte que le « hacker » essayait impunément de pénetrer par FTP mon serveur : il avait identifié un user lui semblant correct (par quelle méthode), et tentait des connexions à une vitesse effrénée.
Comme aucun garde-fou n’empechait cet assaut (type Fail2Ban), il a pu essayer pendant des semaines, jusqu’a trouver le bon mot de passe !!
Resultat : j’ai remplacé tous les mots de passes de mes comptes, et j’ai coupé l’accès FTP à mon serveur (qui ne m’était pas utile en temps normal). Il est toujours possible de réactiver le FTP lorsque j’en ai réellement besoin.
bonjour
merci pour cette info
le changement des mots de passe est fait
par contre effectivement je vais peut être créer un ou deux users FTP avec des noms « à la con » et virer les autres
je pense qu’étant hébergé chez web4all, ce genre d’attaque doit être détecté (enfin, j’espère !)
Cordialement
François
C’est assez simple à détecter : il suffit de tenter plusiers connexions ftp « rapidement » et tant qu’a faire, avec un mauvais mot de passe : Selon la sensibilité avec laquelle a été reglé l’outil, vous serez banni (temporairement, quelques minutes à quelques dizaines) et le serveur ne répondra plus.
ok merci !
Salut,
il existe des outils bien pratiques pour empècher le brute force, ou en tout cas fortement le ralentir. de tels outils existent an tout cas sous Linux (par exemple https://fr.wikipedia.org/wiki/Fail2ban, pour le plus connu), j’ai bon espoir qu’il en existe aussi sous Windows.
avec un tel outils, tu peux par exemple bloquer une ip pendant 1 mois si celle ci échoue à s’autentifier 5 fois en moins de 10 minutes (la durée de blocage, le nombre de d’échecs et la durée de remise à zéro sont configurables). avec un tel paramétrage, un brute force pourra faire 5 tentatives tous les mois (soit 8 ans et 4 mois pour essayer seulement 1000 possibilités). et s’il est assez malin pour ne faire qu’une tentative toutes les 2 minutes pour éviter le blocage, il ne pourra essayer que 750 possibilités par jour. et si ces chiffres te semblent encore trop élevés, tu peux diminuer la tolérance aux échecs.
attention toutefois à ne pas être trop intolérant aux echecs, ça serait dommage de se bloquer soi-même pendant 6 mois car on s’est trompé une fois en tappant son mot de passe 😉
Bonjour
je pense qu’un outil de ce genre doit exister (j’espère) chez l’hébergeur – web4all
mais le blog est hébergé en mutualisé donc je ne peux pas intervenir au niveau système…
cordialement
François
Bonjour,
Merci pour ce retour d’expérience.
Etrangement 1 de mes blogs sous wordpress a subit des attaques en même temps que le votre, pour l’instant impossible de savoir par où ils sont passés (brute force, wordpress, plugins, theme, …) c’est un peu galère car énormément de temps à passer pour tout remettre d’aplomb, sans avoir la certitude d’être tranquille après 🙁
Bonjour
vous êtes chez web4all aussi ?
cordialement
François
Bonjour,
Désolé pour l’oubli, c’était la principale raison de mon commentaire… Oui je suis chez Web4all depuis plusieurs années, et 0 hacks à ce jour malgré plusieurs wordpress.
Une analyse des logs HTTP apache donnerait peut-être une piste pour voir les requêtes suspicieuses ayant pu mener à ce hack.
Effectivement ! Pour quelqu’un qui n’est pas dans le développement informatique, bravo François ! Bon courage pour la suite ! 🙂
Quid de ces deux questions :
Par où sont-ils passés ?
Pourquoi Framboise314 ?
La première question me parait essentielle !
je lui ai aussi demandé, d’où la question d’avoir les logs pour avoir cette infos.
François,
regarde aussi s’il n’y a pas du code indenté à pleins de tabulations (ce qui fait que le code pourri « rajouté » n’est pas visible dans ton éditeur de texte…
Cdlt.
Bravo et merci pour ton retour d’expérience.
Yeah ! Je suis dans l’article !
Plus sérieusement, j’espère que mon lien t’as servi et te servira 😉
Bonjour Amaury
j’ai pour habitude de citer mes sources 😉
et de rendre à César ce qui lui appartient !
un scan detectify est en route… on verra ce que ça donne
merci encore
cordialement
François
D’accord !
Je serais intéréssé par un retour 😉
De toutes facons, vous avez mon facebook 😉
Cordialement,
Pour ma part, la protection commence par
– mettre le wp-config.php avec lecture seule sur le propriètaire du fichier ( FileZilla : 400)
– ensuite tous mes utilisateurs FTP ou WordPress ont un nom d’utilisateur de 20 caractères avec chiffres, lettres minuscules et majuscules, et les mot de passe: 20 caractères avec tout (chiffres, symboles, majuscules et minuscules)
Bonjour Nicolas
le 400 c’est fait pour wp-config
par contre je n ai pas durci les mots de passe à ce point mais… je crois que je vais y songer 😉
ninja firewall me rapporte 68% de Critics dans Hacking attempts severity 🙁
ralalala
apparemment il y a aussi plein de rejets de tentatives d’accès dans le log par l’@ip 52.17.9.21
bonne journée
cordialement
François
Bonjour
Peut être y a t il un lien avec la sortie imminente de windows 10 ?
Faire disparaître toute trace d un autre os sur le pi 😉
ah oui!!! je n’y avais pas pensé 😉
pour la modif de ton fichier php.ini il faut que tu ouvre un ticket chez web4all avec les modifs et ils le feront pour toi.
apparemment l’@ IP citée est détectée comme « un peu trop » active par certains sites…. elle provient d’une plage d’@ IP d’amazon !!!
bonjour,
J’ai moi-même vécu un jour le piratage de mon site. Du code en base64 avait été ajouté à mon footer. Provoquant un avertissement de la part de Google à tous les visiteurs se rendant sur mon site, indiquant que j’étais un site frauduleux. A l’époque, je m’occupais peu du site faute d’en avoir le temps. c’est Bitdefender, avec qui j’étais en partenariat qui m’a prévenu. Un de leur expert a gentiment accepté de me venir en aide. En quelques minutes, il a trouvé la faille. Un plugin troué !
j’ai restauré les fichiers qui avaient été modifié et la base de donnée et j’ai viré le plugin troué car pas de mise à jour proposé!
Aujourd’hui avec Nalaweb, j’utilise Wordfence et Cloudflare.
Cloudflare me propose un système de cache mais également des sécurités comme une protection contre les DDOS. Le plugin Wordfence me protège contre les accès infructueux au tableau de bord (les pirates indélicats voient leur IP banni), wordfence m’averti immédiatement quand une faille est découverte sur l’un de mes plugins et me propose une mise à jour si celle-ci est disponible, il scanne également les fichiers présents sur mon FTP à la recherche de modifications. Si un fichier a été modifié depuis son dernier scan il m’en informe immédiatement.
Bref Wordfence est devenu indissociable de WordPress chez moi, ça n’utilise pas beaucoup plus de ressources et ça me permet de dormir l’esprit tranquille. Je le recommande chaudement à tout ceux qui en ont besoin et tous m’en ont remercier par la suite tellement ils en sont ravis 🙂
Je vous conseille donc de jeter un oeil à ce plugin pour vous éviter une autre mésaventure comme celle-ci.
Je me permet de laisser un lien vers un article où je donne quelques conseils pour se protéger d’un piratage : http://nalaweb.com/comment-se-proteger-du-piratage-de-son-site-internet/
J’espère qu’il sera utilise à un lecteur de framboise314. 😉
bonne journée.
Bonjour
merci pour toutes ces informations.
J’ai installé ninjafirewall qui intervient avant que le php soit exécuté pour filtrer tout le bazar !
il scanne également les fichiers et m avertit de toute modif (droits ou contenu)
hier j ai modifié .htaccess et uploadé des images et j’ai bien eu ces modifs dans la liste qu’il m’a envoyé.
je vais regarder Wordfence de ce pas
Et oui, c’est certain que ces infos et votre lien seront utiles !
merci encore
Cordialement
François
Bonjour,
Votre commentaire m’a fait sursauter !
Bitdefender est à coups sûr le responsable du piratage de votre site .
Ils ont des équipes en place pour analyser répertorier toutes les failles sur tous les logiciels . En vous piratant et en réglant le problème rapidement ils vous ont mis en confiance . Réfléchissez à ce que je vous dis , et ne faites confiance qu’à votre hébergeur et vous même pour la sécurisation de votre site .
bonjour
« à coup sur » est sans doute exagéré
il y a des dizaines-centaines-milliers ? de moulinettes qui balayent le web à la recherche de failles pour implanter des serveurs de spam ou autres…
cordialement
François
Bonjour François ,
Oui ils sont des centaines de milliers à mettre des coups d’épée dans l’eau , Au final une très infime proportion des attaques finissent par aboutir . Et là on nous dit qu’en plus le site est en partenariat avec un prétendu géant de la sécurité web ? Avouez que ça choque . Je ne voudrais bien sûr donner de leçons à personne, mais une des règles est de limiter au maximum le nombre des intermédiaires ayant contrôle sur votre site . Je ne pense pas qu’un hébergeur pourrait trahir un de ses clients , alors si il n’y a que vous pour avoir la main sur le site en plus de lui vous ne craignez pas grand chose . WordPress et autres « gros » cms peuvent être paramétrés pour vous avertir des mises à jour . Reste le problème des plugins, modules tiers , celà nécessite une surveillance assez soutenue, je l’avoue .
En tout cas, longue vie à votre site,en plus d’être une mine d’infos, c’est vraiment une source abondante d’inspiration ( vous m’avez donné envie de m’informer en vue de l’acquisition future d’un drone 😉 )
moi aussi… pour le drone 😉
cordialement
François
Il y a quelques années, l’utilisation de Filezilla était problématique. Car des pages infectées, infectaient ton navigateur et Filezilla pour contaminer tes propres pages web et ainsi de suite.
Si j’étais toi je passerai aussi sur un autre logiciel de FTP.
Merci pour ce retour. J’ai connu la même galère mais il y a une extension qui m’a tout nettoyé et du coup j’en ai profité pour faire un don à l’auteur. Voici le nom de l’extension : Anti-Malware and Brute-Force Security by ELI !
Merci beaucoup pour l’info
je note (pour la prochaine fois 😉 )
mais de mon côté c’est reparti j’ai tout réinstallé depuis les sauvegardes
et installé ninjafirewall qui intervient avant wordpress
cordialement
François
@popole
Bitdefender le responsable à « coups sûr » ?
Qu’est ce qu’il faut pas entendre !? … Un bon vieux troll des familles !
Comme l’a dit François, il y a des centaines et des centaines de scripts qui parcourent les URL du net dans le but de trouver une faille dans laquelle s’engouffrer. Encore aujourd’hui, Wordfence m’a bloqué des dizaines d’adresse IP qui tentent régulièrement d’accéder à la partie admin de mon site ou de faire des scans d’URL (je reçois un mail à chaque erreur 404 et je peux te dire que les url ne sont pas des fautes de frappes, mais bel et bien des urls qui n’existent pas, des tests d’URL de plugins que je n’utilise pas dans le but d’utiliser une vulnérabilité connue sur ces plugins.)
Les éditeurs d’antivirus ne sont pas les principaux créateurs de virus, merci de ne pas répandre ces légendes urbaines !