Sujets-libres.fr

Informatique, logiciels libres, internet, humeurs et… le reste !

Wordpress

Blog compromis, ma réponse à l'incident

Rédigé par -Fred- / 06 octobre 2015 / 2 commentaires

Je vois peu de retours d'expérience concrets sur le net, alors je vais vous livrer le mien. Je ne suis pas spécialiste de la question. Mon analyse est donc probablement imparfaite ou incomplète. Toutefois, je le fais pour plusieurs raisons :

  • Les quelques visiteurs qui passent ici doivent savoir si mon blog est, ou a été, à risque.
  • Communiquer sur un cas réel me semble intéressant. Il est désagréable de parler de son propre cas mais au moins, j'ai accès à toutes les informations.
  • Si je suis en mesure de faire des erreurs, je ne dois pas être le seul. Expliquer quelles ont été mes erreurs pour que d'autres ne les commettent pas ne peut être que bénéfique.
  • Donner la possibilité à mes visiteurs de me faire un retour, notamment sur ma manière de réagir à cet événement, sera peut être pour moi l'occasion de progresser.

Analyse

Comment cela a été possible ?

J'ai passé un peu plus de temps à analyser mes logs et les seules informations que j'ai pu trouver se trouvent dans les logs d'apache. Rien ailleurs et pour cause, les faits datent du 5 novembre 2014. Il n'y a donc plus rien à voir dans les autres logs depuis longtemps.

Je constate donc une forte activité de la part de l'attaquant le 5 novembre 2014, date à laquelle l'un des fichiers a été déposé et exploité. Le fichier en question est un script php déposé dans un répertoire que j'avais créé manuellement à la racine de mon blog wordpress (pas grand chose dans ce dossier à part des photos présentes sur mon blog et quelques bricoles).

Je suspecte donc que l'un des plugins ou l'un des thèmes utilisé sur mon blog contenait une faille permettant l'upload de fichiers. Je précise toutefois que les plugins et thèmes utilisés proviennent tous de sources officielles (trouvés et installés via le panel d'administration du blog). J'écarte peut être trop vite Wordpress lui même mais dans le mesure où il se met à jour automatiquement, les failles connues sont comblées rapidement. Sauf à exploiter une 0 Day, c'est donc peu probable.

Certains répertoires avaient aussi des autorisations trop élevées. Je ne pense pas que ce soit du fait de l'attaquant mais plutôt moi qui a certainement un jour modifié cela (suite probablement à un problème de mise à jour wordpress).

Les logs montrent par ailleurs que pour lister les failles de mon blog et de quelques sites hébergés sur mon serveur, l'attaquant à utiliser au moins un outil open source de recherche de vulnérabilités web. L'outil en question est intéressant pour deux raisons. D'une part, il permet d'auditer ses propres sites, et d'autre part, il me permet de comprendre certains comportement étranges de mon serveur il y a quelques mois (CPU serveur chargé à presque 100% à cause d'un nombre anormal de processus apache2). J'ai donc compris que mon serveur avait fait l'objet de scans en vue d'y trouver des vulnérabilités.

A quoi servaient ces fichiers ?

Le premier fichier n'était clairement fait pour ne pas être lisible facilement (instructions codées en ascii, codes en base64, gzinflate...). Une fois décodé, il montre un peu plus ce à quoi il est destiné car il contient tout un tas de commandes permettant notamment de rechercher des fichiers sensibles du système (utilisable en environnement *nix ou windows). J'ai exécuté le fichier en machine virtuelle dans firefox (avec le module firebug) et je vois qu'il tente de se connecter à des ressources dispo sur un site externe (je continue à essayer de comprendre plus de ce côté là).

L'exécution du scripts en question en machine virtuelle montre qu'il tente de communiquer avec un serveur distant. Le domaine de ce serveur est en .ro . A ce que je peux voir rapidement, ce serveur héberge un certain nombre d'outils permettant le piratage de sites web.

Un autre fichier a été déposé plus récemment (fin juillet) et contient un exploit selinux. Un autre répertoire contient, si je comprend bien, un outil d'analyse open source. Je ne trouve pas de trace quand à l'utilisation de l'un ou l'autre de ces outils, contrairement à l'autre outil dont je parle au dessus et pour lequel je peux voir que l'attaquant l'a utilisé environ 1h sur ma machine.

Comprendre ce qui a été fait et les motivations

Je constate que l'attaquant a possiblement disposé d'une bonne vue de la structure des différents sites hébergés sur mon serveur et accessibles. Il ne me semble pourtant pas que des dégâts aient été fait. Rien non plus en base de donnée (en tout cas, s'il y a eu quelque chose à une époque, il n'en reste rien).

Actions

Actions curatives

Comme détaillé dans un billet récent, j'ai très rapidement vérifié que ma base de donnée Wordpress était saine. J'ai ensuite réinstallé une instance toute propre de Wordpress sans aucuns plugins, histoire d'avoir une solution fonctionnelle le temps de trouver une solution plus durable et plus sûre pour mon blog. La solution retenue a donc été de passer à Pluxml car l'outil correspond parfaitement à mes besoins.

Actions préventives

Pour ne pas avoir à subir un nouvel épisode de ce type, j'ai décidé d'être plus strict au niveau de la gestion de mon serveur. J'ai donc déjà nettoyé et réduit au maximum le nombre de services ouverts sur l'extérieur. Que ces autres services n'aient pas été touchés aujourd'hui ne signifie pas qu'ils ne le seront pas à l'avenir ou qu'ils ne puissent pas donner d'informations à d'éventuels attaquants. Certains services utiles ne sont plus ouverts qu'en local (munin notamment) et d'autres sont tout simplement fermés (webmail rainloop). Au niveau Web, je n'ai conservé sur l'extérieur que ce blog et deux pages statiques.

J'effectue à présent un suivi de l'activité de mon serveur de manière plus stricte. Je suis en train de réfléchir à automatiser ce qui peut l'être et qui est spécifique à mon installation. J'ai un peu chamboulé mon programme de pré-rentrée afin de remettre un peu d'ordre là où c'était nécessaire.

Conclusions

Mes erreurs ont été multiples. Je considère avoir globalement été trop laxiste, que ce soit au niveau de mes réglages apache qu'au niveau des services ouverts sur ma machine. Peu regardant aussi sur l'activité de mon blog. J'aurais, si j'avais bien fait les choses, dû voir immédiatement l'arrivée de ces fichiers.

Je considère avoir eu de la chance. Cette expérience m'a permis de connaitre l'existence d'outils intéressants d'audit de sites web. Je vois d'ailleurs mieux comment se comporte mon serveur lorsqu'il fait l'objet d'une analyse par ce type d'outil.

J'ai aussi pris conscience de l'importance des logs. Il est donc essentiel d'être réactif, sous peine de ne pas avoir de données exploitables. Se faire poutrer une fois, ça peut arriver. Ne pas avoir les éléments pour réagir, c'est l'assurance que ça arrivera une seconde fois.

Migration Wordpress vers Pluxml

Rédigé par -Fred- / 22 septembre 2015 / 4 commentaires

Suite aux problèmes de sécurité que j'ai rencontré récemment via mon blog sous Wordpress, j'ai décidé de réagir. Ma réaction suite à l'incident en question sera détaillée dans un prochain billet. Toutefois, l'une des choses que j'ai décidé est de changer de moteur de blog et de migrer vers Pluxml.

J'apprécie Wordpress au quotidien, notamment le côté intuitif à mon sens de l'interface d'administration. Malgré cela, c'est une usine à gaz. Pour un usage normal il n'est normalement pas nécessaire de mettre les mains dedans. Toutefois, le côté ultra complet de ce CMS et le nombre impressionnant de plugins qui peut l'accompagner reste une source problèmes potentiels.

J'ai donc étudié plusieurs options afin de pouvoir bloguer un peu plus en paix...

Conserver Wordpress en l'état

La solution la plus simple. J'ai d'ailleurs refait une installation propre de Wordpress lorsque j'ai constaté mon problème. Malheureusement, j'ai un peu moins confiance dans ce CMS et je n'ai pas été en mesure de déterminer comment exactement l'attaquant s'y était pris. L'outil est certes très puissant et configurable mais la contrepartie, c'est qu'il est plus difficile pour la communauté WP de le rendre sûr. Donc, j'ai pris la décision de trouver une alternative.

Conserver partiellement Wordpress

Solution nécessitant un peu de développement de ma part. L'outil Wordpress pour rédiger mes billets et une interface minimaliste codée par mes soins pour accéder aux billets en lecture seule. Gros avantage, mes visiteurs n'ont plus à interagir directement avec Wordpress car finalement, seule la base de donnée est commune. Gros inconvénients, d'une part je perd l'intérêt du blog si les visiteurs ne peuvent plus laisser de commentaires et d'autre part, plus de flux rss de disponibles, sauf à coder ça moi même. Bref, bonne idée sur le moment mais au final je risquais d'accoucher d'un truc limité et pas forcement moins buggué que Worpress. Ce n'est donc pas la solution à retenir ici.

Changer carrément de moteur de blog

Encore faut-il trouver chaussure à son pied et quitter un CMS pour un autre tout autant à risque, ça n'a pas vraiment d'intérêt. J'ai donc fait le tour de quelques moteurs de blog et pour faire court, je me suis arrêté sur Pluxml. J'apprécie de pouvoir y trouver les fonctionnalités de base pour un blog sans m'encombrer de ce que je trouve accessoire. J'apprécie aussi qu'il fonctionne sans base de donnée. J'ajoute que j'ai opéré ma migration depuis Wordpress grâce à "wp2pluxml" (l'outil ne fait pas tout mais permet un gros gain de temps).

Des détails sont encore à régler mais la migration est opérée.