Récit de l’attaque via PHP de mon blog. En cause : timthumb.php

Ce matin, en regardant mon tableau de bord Analytics, j’ai découvert des pages bizarre affichées sur mon blog. Bizarre car les urls ne correspondaient pas au pattern que je leur ai donné sur mon blog… Et surtout, en allant voir ce que donnaient ces pages HTML, j’ai eu la très mauvaise surprise de constater que celà renvoyait des pages visuellement avec le même thème que mon blog, mais avec des textes ayant trait à tout ce que l’on peut trouver de pharmaceutique dans le dossier « spam » de sa boite mail… Ce dans des langues différentes du français : globalement c’était de l’allemand et de l’espagnol. Bizarre, car même les liens de mon blog étaient traduits (les pages en haut et la description à droite).

Ni une, ni deux, j’ai commencé à chercher d’où celà pouvait venir. J’ai regardé mes conf Nginx et Apache, puis en les arrêtant l’un après l’autre, mais il semblait que ces pages étaient bien liées à mon blog (il ne s’agissait pas d’une redirection quelconque). Donc je me suis demandé si ces pages n’étaient pas en fait stockées sur ma base de donnée WP. Après un petit tour sur mon phpmyadmin, j’ai constaté que rien ne venait de là et qu’à priori ma BDD était propre. Soulagement, mais chose très bizarre car le root de mon dossier de blog était vide de ces pages HTML…

J’ai alors décidé de voir ce qu’il se passerait si je changeais de thème de mon blog. Ce que j’ai fait en mettant le blog Cordobo Green Park. Mais là, les pages infectées conservaient leur thème d’origine (= le thème de mon blog que j’utilise depuis plus d’un an : Splendio). Donc je me suis dit que c’étaient des pages HTML qui devaient être stockées sur mon blog, quelque part, mais c’était quand même bizarre puisque ces pages n’étaient pas à la racine de mon blog…

Du coup, ça pouvait être aussi un exploit des différents scripts PHP utilisés sur mon blog… Je me souvenait notamment avoir vu ces derniers jours des appels récurrents sur mon compte Analytics de certains fichiers PHP sur mon blog, mais j’avais opté pour le bénéfice du doute (et l’absence de moyen : j’avais sérieusement autre chose à faire ces derniers jours), et je n’avais rien fait.

Donc j’ai cherché via fgrep (fgrep -r « genannten » ./*), en prenant un des mots que je trouvais dans les pages infecté, de préférence un mot que je n’aurais pas moi-même utilisé. Ici : « genannten ». Et j’ai lancé la recherche depuis la racine de mon blog pour savoir si, quelque part, je pouvais trouver ce genre de fichier. Et là, victoire, j’ai trouvé.

Et, comme vous pouvez vous-même le voir, tous les fichiers ont été mis dans le dossier wp-content/uploads/js_cache/.thumbs . Première chose, j’ai fait un gros remove (rm *.html). Ca ne corrige que le symptome et pas la cause, mais je n’ai pas encore trouvé correctement d’où pourraient venir ces fichier html.

Sachant que le dossier js_cache ne contient pas grand chose, à part des fichiers ressemblant à ça : tinymce_8ad9cfac1dd584c1bc27cf58437793d3.js … J’ai fait un vi sur ces fichiers, et je ne pense pas que cela puisse trop venir de là…

La bonne nouvelle, c’est que la commande fgrep ne renvoie rien sur les autres sites fonctionnant sur le même serveur.

EDIT : Dans mes souvenirs, le fichiers fréquemment appelé s’appelait « tools.php ». Je croyais que c’était un truc de mon blog, et du coup je n’y avait pas touché. Mais j’ai retrouvé ce fichier, il était dans wp-content/themes/splendio/scripts/cache. J’ai viré ce fichier (ou plus exactement, je l’ai renommé), et je vais regarder ce que ça casse sur mon blog ou non. Si ça ne casse rien, je considérerai que ce fichier a été mis chez moi à mon insu, et donc que je peux définitivement le virer.

Je crois que ce fichier a pu être uploadé sur mon serveur via le script timthumb.php que j’ai mis sur mon serveur moi-même (il me permet de créer des fichiers images plus petits sur les pages de mon blog). Probable que ce script php contienne des failles facile à exploiter.

In fine : j’ai mis à jour le script timthumb avec la dernière version disponible sur le site Google Code, mais celui-ci ne fonctionnait pas : il me sortait une erreur PHP « Parse error: syntax error, unexpected T_PROTECTED in ». Donc j’ai décidé de virer tout simplement timthumb.php et d’utiliser autre chose dans mon plugin similar_post.

Edit 2 : Rah, j’en ai retrouvé dans le répertoire wp-content/uploads/2008/03/.svn de mon blog 🙁 C’est supprimé, mais pour ceux-là je vois pas comment ils sont arrivés…

Edit 3 : Cloudflare a bien vu que j’étais particulièrement attaqué à ce moment !

8 réflexions sur « Récit de l’attaque via PHP de mon blog. En cause : timthumb.php »

  1. Cela fit pratiquement un an que ce problème est apparu (http://korben.info/timthumb-exploit-wordpress.html) , j’avais eu quelques soucis avec ce script, notamment avec des thèmes de chez Elegant
    http://www.elegantthemes.com/troubleshooting-timthumb.html

    2 types de pb, des fichiers qui envoyaient du spam ou alors le config.php modifié (plus de 4000 lignes, c’est assez étrange, le code malicieux n’apparaissant que vers la 2000 ième ligne, le rest étnt en blanc.

    RépondreRépondre
  2. @Philippe: Pour ma part, je viens de vérifier le wp-config.php, et il n’a rien. Par contre j’ai toujours pas trouvé où est le script qui génère des milliers de pages.

    Je pensais être à l’abris de Timthumb (j’avais lu le billet de Korben), car je n’avais laissé que Flickr comme site autorisé, mais en fait non, je me suis fait avoir par ce biais. En tout cas merci pour ton commentaire, je me sens moins seul 🙂

    RépondreRépondre
  3. L’idée est peut être de tout nettoyer, en faisant une sauvegarde, puis en supprimant tous les fichiers.
    Ensuite tu rebalances les fichiers de WP, les dossier uploads, themes et enfin tu réinstalles les extensions (c’est comme cela que j’ai nettoyé les différents sites).

    RépondreRépondre
  4. @Philippe: Alors j’y ai pensé, mais le problème c’est que j’ai retrouvé pas mal de petits scripts « infectés » dans mon répertoire de cache de WP, donc si je le copie pour le remettre juste après, ça va pas servir à grand chose 🙁

    RépondreRépondre
  5. Pas sûr, un script peut avoir été infecté lors d’une version précédente (mise à jour de sécurité effectuée un peu tardivement par exemple). Peut être qu’une installation avec la dernière version suffirait. Ou alors le script est pourri et il faudra s’en passer.

    RépondreRépondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.