Deux mois sans publier. Et pour cause.
Le 16 juin dernier, je publiais un article sur le blog ainsi qu'un post LinkedIn pour revenir sur une étape assez particulière : plus de 300 sites patchés à la suite d'une vulnérabilité critique.
Je terminais alors le post par une phrase plutôt optimiste :
« On va maintenant essayer de reprendre un rythme un peu plus... normal 😄 »
Quelques jours plus tard, autour du 23 juin, je publiais à nouveau sur LinkedIn pour faire le point sur les dernières interventions de sécurité. Spoiler : le retour à un rythme « normal » n'aura pas duré bien longtemps.
Nous sommes aujourd'hui le 11 août et, depuis ce dernier post, je n'ai rien publié. Ni sur LinkedIn, ni sur le blog. Pas parce que je n'avais rien à raconter, bien au contraire.
Depuis fin juin, les failles se sont enchaînées, tout comme les correctifs, les mises à jour, les nettoyages de sites compromis et les interventions de sécurité. Ces dernières semaines ont tout simplement été consacrées au travail.
Faille sur faille, mise à jour sur mise à jour
Après les premières interventions de juin, les alertes ont continué à s'enchaîner. Il y a eu des sites compromis à nettoyer, des vulnérabilités à corriger, des extensions à mettre à jour, des sites WordPress à désinfecter et sécuriser, mais aussi des interventions directement sur des serveurs et des correctifs à déployer rapidement.
À cela s'ajoutent toutes les vérifications qui suivent une mise à jour ou un nettoyage, car appliquer un correctif ne suffit pas toujours à considérer une intervention comme terminée.
Parmi les interventions réalisées pendant cette période, on retrouve notamment des nettoyages de sites compromis à la suite de la faille JCE, la désinfection d'un serveur cPanel/WHM dont plusieurs sites étaient infectés, des mises à jour liées à la vulnérabilité de PageBuilder CK, le nettoyage et la sécurisation de plusieurs sites WordPress ou encore le déploiement du correctif Helix3 3.1.1.
À chaque fois, le même impératif revenait : corriger rapidement, puis vérifier que le problème ne se limitait pas à la vulnérabilité elle-même.
Un rythme de maintenance particulièrement soutenu
Ce qui devait être une période de retour à un rythme plus normal s'est finalement transformé en plusieurs semaines de travail intensif. Et c'est probablement ce qui explique le mieux mon silence sur le blog.
Quand plusieurs centaines de sites sont concernés par une vulnérabilité, la priorité n'est pas d'écrire un article à son sujet : la priorité est de les patcher. Lorsqu'un site est compromis, la priorité n'est pas non plus de publier un retour d'expérience, mais de le nettoyer. Et lorsqu'un serveur hébergeant plusieurs sites présente des signes de compromission, la priorité est encore plus évidente : il faut intervenir.
L'écriture attendra.
Des vulnérabilités différentes, mais des mécanismes qui se ressemblent
Avec un peu de recul, ces différentes interventions ont pourtant fait apparaître un constat assez intéressant. Les CMS et les extensions concernés étaient différents, mais plusieurs vulnérabilités exploitaient un principe relativement similaire : une fonctionnalité exposée par une extension, avec un contrôle insuffisant des autorisations.
Un cas fréquent concerne notamment les endpoints AJAX. L'extension prévoit une action qui doit normalement être réservée à certains utilisateurs et vérifie bien la présence d'un jeton de sécurité, mais oublie de vérifier correctement que l'utilisateur est réellement autorisé à effectuer cette action.
La requête peut alors être considérée comme valide alors qu'elle ne devrait pas l'être. Et selon la fonctionnalité concernée, les conséquences peuvent être importantes.
D'un endpoint mal protégé à une compromission complète
Selon la vulnérabilité exploitée, un attaquant peut notamment parvenir à téléverser des fichiers arbitraires, écrire ou supprimer des fichiers, exécuter du code, déposer une backdoor PHP ou encore mettre en place un mécanisme de réinfection.
Dans certains cas, il peut également modifier des fichiers utilisés par les moteurs de recherche, comme robots.txt ou sitemap.xml, afin de détourner le référencement du site.
Une fois du code malveillant présent sur un site, le problème ne consiste donc plus simplement à installer la dernière version de l'extension. Il faut déterminer si le site a été compromis et, si c'est le cas, procéder à son nettoyage tout en recherchant les éventuels mécanismes permettant à l'attaquant de revenir.
Le plus inquiétant : rien ne semble forcément anormal
C'est un point qui revient régulièrement lors des nettoyages : un site compromis peut continuer à fonctionner parfaitement en apparence.
La page d'accueil s'affiche, les formulaires fonctionnent, les visiteurs peuvent naviguer et l'administration peut même sembler parfaitement normale. Il n'y a pas forcément d'écran blanc, de message d'erreur ou de symptôme immédiatement visible.
Pourtant, une backdoor peut être présente quelque part sur le serveur et être utilisée discrètement.
C'est ce qui rend ces compromissions particulièrement problématiques : le fonctionnement apparent du site ne permet pas nécessairement de savoir qu'il a été compromis.
Une infection peut chercher à revenir
Le nettoyage d'un site compromis ne consiste donc pas simplement à supprimer quelques fichiers suspects. Il faut également rechercher ce qui pourrait permettre à l'attaquant de revenir.
Une tâche cron peut notamment être utilisée pour automatiser une réinfection. Dans ce cas, supprimer la backdoor visible sans supprimer le mécanisme qui permet de la recréer revient à traiter le symptôme sans traiter la cause.
C'est pourquoi une intervention de nettoyage doit aller au-delà de la simple suppression des fichiers manifestement malveillants et prendre en compte les mécanismes susceptibles de maintenir la compromission.
Et les conséquences ne sont pas uniquement techniques
Une compromission peut également avoir des conséquences sur le référencement du site. Parmi les symptômes rencontrés, on peut notamment retrouver la création ou la modification de fichiers comme robots.txt ou sitemap.xml, avec pour objectif de détourner le référencement du site.
Un site piraté n'est donc pas uniquement un problème de sécurité informatique. Il peut également devenir un problème SEO, voire un problème commercial si le domaine, les pages ou la réputation du site sont affectés.
C'est un aspect parfois sous-estimé : une attaque peut avoir des conséquences bien au-delà des fichiers qui ont été modifiés sur le serveur.
Le véritable problème n'est pas seulement la découverte des failles
Ce qui m'a le plus marqué pendant ces dernières semaines n'est finalement pas le nombre de vulnérabilités découvertes, même si, grâce ou à cause de l'IA, le rythme des découvertes semble clairement s'accélérer.
C'est surtout la répétition du même scénario.
Une vulnérabilité est découverte, un correctif est publié, puis il faut s'assurer que les sites concernés l'installent réellement. Et c'est là que la maintenance applicative prend tout son sens.
Parce qu'une vulnérabilité corrigée par l'éditeur mais laissée sur un site pendant plusieurs semaines reste une vulnérabilité exploitable sur ce site.
La fenêtre d'exposition
Entre la publication d'une faille et l'installation du correctif, il existe une période pendant laquelle un site est exposé. Plus cette période est longue, plus le risque augmente, notamment lorsqu'une vulnérabilité est connue publiquement et qu'un correctif est déjà disponible.
Dans ce contexte, la rapidité de déploiement devient un véritable enjeu de sécurité.
La maintenance applicative ne consiste donc pas uniquement à garder un CMS « à jour ». Elle consiste aussi à réduire autant que possible cette fenêtre d'exposition.
Maintenir un site, ce n'est pas simplement cliquer sur « Mettre à jour »
C'est probablement la principale leçon que je retiens de ces dernières semaines.
Une maintenance applicative ne devrait pas être considérée comme une simple succession de mises à jour. Il faut surveiller les vulnérabilités, identifier les correctifs importants, prioriser les interventions et déployer les mises à jour dans des délais adaptés à leur niveau de criticité.
Et lorsqu'un site est déjà compromis, il faut être capable d'intervenir pour le nettoyer et vérifier qu'il ne reste pas de mécanisme permettant une nouvelle infection.
C'est un travail beaucoup moins visible qu'une nouvelle fonctionnalité ou qu'une refonte graphique. Pourtant, il devient particulièrement concret lorsqu'une vulnérabilité critique est publiée et qu'il faut intervenir sur des dizaines, voire des centaines de sites.
Deux mois plus tard
Voilà donc pourquoi le blog et LinkedIn sont restés silencieux depuis juin.
Ce n'était pas vraiment une pause, mais plutôt une période où le travail passait avant la publication. Pendant plusieurs semaines, les failles, les mises à jour, les correctifs et les nettoyages se sont succédé à un rythme particulièrement soutenu.
Avec le recul, cette période renforce encore davantage une conviction que j'avais déjà : la maintenance applicative est une mesure de sécurité à part entière.
Chaque correctif appliqué rapidement réduit la fenêtre pendant laquelle un site peut être compromis. Et parfois, le meilleur article que l'on puisse écrire sur la sécurité est celui qu'on n'a pas eu le temps d'écrire parce qu'on était justement en train de corriger les sites concernés.