Comment gérer une intrusion serveur sans expérience en sécurité ?

Le 30 avril j’ai eu à gérer une intrusion sur mon serveur. L’objectif de cet article est de partager cette mésaventure pour permettre à ceux qui se retrouveraient dans la même situation et qui ne possèdent aucune expérience en sécurité informatique (ce qui est mon cas) d’agir de façon correcte.
Comme d’habitude le retour et la critique seront appréciés 😉 .

Le réveil

Samedi 30 avril, après une phase de réveil, je regarde mes courriels. Le 29/04 à 22h20 j’ai reçu un courriel étrange de la part de Google Search Console Tools, sobrement intitulé « Nouveau propriétaire pour http://omnos.fr ». Ça fait peur. Ni une ni deux je me connecte à l’outil de Google et je constate effectivement l’ajout d’un propriétaire et d’une adresse : « http://omnos.cnruby.net ». Il est impossible d’ajouter un propriétaire sans l’ajout d’un fichier sur mon serveur donc je me connecte via SSH et je vais voir. Effectivement un fichier a été ajouté. Ce n’était pas le seul, mais je ne le savais pas encore.

Je décide d’investiguer de façon minutieuse avant de faire quoi que ce soit d’autre. L’auteur du piratage a eu plus de 10 heures devant lui. Par conséquent je n’avais aucune raison de me presser.
Je n’avais pas une idée très claire de ce que j’allais faire ensuite, mais au final mon action peut se résumer en quatre phases :
– Investiguer : comprendre comment l’attaque a eu lieu et sa portée (uniquement sur mon blog WordPress ? Sur les services web ? Sur tout mon serveur ? )
– Bloquer les accès utilisés depuis l’extérieur.
– Réparer les dégâts.
– Savoir si d’autres ont subi ce piratage et les prévenir.

Rétrospectivement je pense que c’est un bon schéma à appliquer, mais comme vous allez pouvoir le lire, la pratique était un peu plus brouillonne.

L’investigation

J’ai regardé les dates de modification des fichiers dans le dossier de WordPress et j’ai vu que les fichiers index.php et xmlrpc.php avaient été modifiés pour rajouter ceci :

Ce code utilise un plugin WordPress désactivé pour connaître l’origine de l’IP et applique une redirection vers un site (qui est une copie de la page d’accueil de mon blog) si l’IP n’est pas française. J’ai eu de la chance, j’aurais pu ne pas remarquer cette intrusion pendant des semaines. Je ne sais toujours pas à quoi cette modification peut lui servir concrètement donc si vous avez une idée signalez-la moi 😉 .
D’autres fichiers ont été rajoutés dans des sous-dossiers. Malheureusement je ne l’ai pas vu tout de suite, car, chose que je ne savais pas, la date de dernière modification d’un dossier ne correspond pas forcément à la date de la dernière modification ou du dernier ajout d’un fichier dans ce dossier.

À partir de ce moment j’ai décidé de demander de l’aide à des personnes plus compétentes. Je conseille à tous d’aller faire un tour sur le channel IRC ##security de freenode en cas de problème.

On a scanné les ports de mon serveur, donné des conseils et regardé si des failles connues existaient sur les différents logiciels installés sur mon serveur pendant que je regardais les logs (SSH, Apache, WordPress). Un peu après que l’un d’entre eux ait trouvé la faille utilisée (une faille de ProFTPD qui aurait dû être mis à jour depuis longtemps dans les paquets de ma distribution), j’ai trouvé, dans les logs de WordPress, des requêtes étranges spécifiques du moment de l’attaque:

Après l’avoir annoncé sur le chan IRC l’un d’eux a répondu que l’attaquant avait utilisé mon installation WordPress cassée.

Je ne sais pas si c’est par manque de temps (il me restait une heure devant moi avant d’être absent) ou si j’espérais que le pirate ait exploité une faille WordPress plutôt que la faille ProFTPD qui a bien plus d’impact. J’ai choisi d’attribuer la faille exploitée à WordPress (ou à ma configuration de WordPress) et de passer au blocage du pirate. Je regarderai ce fichier cacheplugin.php plus tard.
Cette grave erreur m’a coûté une investigation plus poussée à faire à posteriori.

Le blocage

J’ai désinstallé ProFTPD. J’ai coupé l’accès du pirate mais j’ai perdu les logs (purge).
J’ai fait les mises à jour système (que j’effectue régulièrement). Les mises à jour ont modifié beaucoup de fichiers ce qui a rendu mon investigation avancée plus compliquée.
J’ai changé le mot de passe de la base de données utilisée par WordPress. C’était nécessaire.
J’ai fait un cp sur le dossier contenant le blog puis j’ai remplacé le contenu de l’original par un index.html annonçant le problème. J’aurais dû faire un mv pour ne pas changer les dates de dernière modification.

Je pars de chez moi.

L’investigation avancée

Entre-temps j’ai été contacté par Vassili qui a proposé son aide pour chercher d’autres sites piratés par la même personne.
De retour chez moi j’accepte son aide et je regarde le fichier cacheplugin.php situé dans wp-admin/network. Il me semble très étrange d’avoir un fichier WordPress comme cela, je télécharge donc une version propre et effectivement ce fichier n’est pas présent. Un autre du même dossier est spécifique à mon installation, le dénommé debugvr.php contenant :

Et voilà, je me rends compte que c’est la faille de ProFTPD qui a été utilisée. Ça change tout.
J’utilise find pour trouver tous les fichiers modifiés durant la période de l’attaque :

Puis pour trouver tous les fichiers modifiés depuis (ils auraient pu être remodifiés par le système ou moi-même):

Cela m’a pris beaucoup de temps et j’ai pu manquer des choses. N’ayant rien trouvé d’autre de suspect j’ai décidé de remettre le blog en ligne.

La remise en ligne

J’ai conservé la même base de données, changé le mot de passe de mon compte et récupéré une installation WordPress propre à laquelle j’ai ajouté les médias, puis réinstallé les extensions.

Que faire d’autre ?

C’était plutôt difficile et long, mais je suis content d’avoir eu de la chance dans ma malchance. La faille aurait pu permettre de faire bien pire.

Il me reste bien sûr à contacter les sites web trouvés par Vassili. Je compte également faire une réinstallation complète à moyen terme (j’ai peut-être loupé des choses). Si vous avez d’autres suggestions n’hésitez pas 😉

Comment gérer une intrusion serveur sans expérience en sécurité ? par La Réponse est 42 est sous Licence Creative Commons Internationale Attribution-Partage à l'identique 4.0.

Vous aimerez aussi...

2 réponses

  1. Cascador dit :

    Salute,

    Piratage = réinstallation et dans l’immédiat. C’est bien d’apprendre et de savoir comment le piratage a eu lieu mais une fois que ton serveur n’est plus sûr, le seul moyen c’est de le réinstaller.

    Je rappelle qu’on peut modifier les dates des fichiers/dossiers : http://www.shellhacks.com/en/Faking-a-Files-Access-Modify-and-Change-TimeStamps-in-Linux

    Tcho !

    • Astyan dit :

      C’est certain que c’est la meilleur solution. Malheureusement, comme tout le monde, mes journées ne sont pas extensibles. Je n’aurais pas pu faire de réinstallation immédiate sans perte de services (je n’ai pas que WordPress sur mon serveur). C’est pour cela que je ferais une réinstallation lorsque j’aurais plus de temps.

Laisser un commentaire

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