Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Les modules et extensions abandonnés : le premier vecteur réel

Avant le mot de passe faible, avant le serveur mal configuré, le point d’entrée le plus courant reste un module ou une extension que plus personne ne met à jour, installé pour une fonctionnalité ponctuelle puis oublié.

Décrire mon problème Discuter sur WhatsApp

Ce qu’est réellement un module abandonné

Un module abandonné n’est pas forcément un module ancien ou visiblement cassé. C’est un module installé un jour pour un besoin précis, un moyen de paiement, une bannière promotionnelle, une intégration réseau social, puis laissé en place sans être ni utilisé activement ni surveillé. Son éditeur peut avoir cessé son activité, arrêté de le maintenir, ou simplement ne plus publier de correctif pour une version ancienne encore installée sur votre boutique.

Le cœur du CMS, lui, continue d’évoluer. Chaque nouvelle version publie parfois des correctifs de sécurité qui concernent indirectement les modules, et de nouvelles failles sont régulièrement découvertes dans du code qui n’a pas changé depuis des années. Un module abandonné ne devient donc pas seulement inutile : il devient une zone du site qui s’écarte de plus en plus du niveau de sécurité du reste de l’installation.

  • 39,1 % des applications CMS compromises étaient déjà obsolètes au moment de l’infection
  • 13,97 % des sites compromis avaient au moins une extension ou un thème vulnérable au moment de la remédiation

Rapport Sucuri 2023, Hacked Website & Malware Threat Report

Le cas Slider Revolution : une extension qu’on ne sait même pas avoir

En décembre 2014, la campagne connue sous le nom de « SoakSoak » a compromis plus de 100 000 sites WordPress via une faille de l’extension Slider Revolution, selon le décompte publié à l’époque par Sucuri. La particularité de ce cas : l’extension était très souvent intégrée directement à l’intérieur de thèmes premium, sans que l’acheteur du thème ne sache même qu’elle s’y trouvait. Sans le savoir installée, elle n’était évidemment jamais mise à jour. Google a mis en liste noire plus de 11 000 domaines pendant cette campagne, d’après les analyses de Sucuri et de Graham Cluley. C’est l’exemple le plus clair d’un vecteur d’entrée qu’un marchand ne peut pas surveiller s’il ignore son existence.

Pourquoi certaines failles corrigées restent exploitables

Le module de liste de souhaits blockwishlist pour PrestaShop, en versions 2.0.0 à 2.1.0, contenait l’injection SQL référencée CVE-2022-31101, corrigée en 2.1.1. C’est le maillon qui rendait exploitable la faille du cœur CVE-2022-36408 (aussi référencée CVE-2022-31181), laquelle visait les versions 1.6.0.10 à 1.7.8.6 incluses et a été corrigée en 1.7.8.7. Mais sur toutes les boutiques où ce module précis n’a jamais été mis à jour ou remplacé, la porte d’entrée est restée ouverte bien après la publication du correctif : la faille n’avait pas disparu, elle avait simplement cessé d’être un problème pour ceux qui avaient agi.

Comment repérer un module à risque sur votre boutique

  1. Vérifier la date de dernière mise à jour

    Dans le back-office, chaque module ou extension affiche généralement sa version et parfois sa date de publication. Un module qui n’a pas bougé depuis plusieurs années, alors que le cœur du CMS a changé plusieurs fois, mérite d’être vérifié.

  2. Vérifier qu’il reste disponible officiellement

    Un module qui a disparu du dépôt officiel ou de la marketplace de l’éditeur, alors qu’il reste actif sur votre site, ne recevra plus aucun correctif futur.

  3. Vérifier la compatibilité annoncée

    Un module qui annonce une compatibilité maximale très inférieure à la version actuelle de votre CMS a de fortes chances de ne plus être suivi activement par son éditeur.

  4. Lister les modules réellement utiles

    Un module installé pour un test ponctuel ou une campagne terminée depuis longtemps, mais toujours actif, augmente la surface d’exposition sans apporter aucun bénéfice.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Depuis quand le problème est-il constaté ?

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?
Avez-vous encore accès à l’administration WordPress ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Comment savoir si un module que j’utilise a déjà été touché par une faille publiée ?
Je compare la liste des modules installés et leurs versions aux bases publiques de vulnérabilités connues, et je vérifie les journaux du site pour détecter une éventuelle exploitation déjà survenue.
Dois-je supprimer tous les modules que je n’utilise plus ?
Oui dans la grande majorité des cas. Un module désactivé mais toujours présent sur le serveur reste souvent exécutable directement, ce qui ne le rend pas plus sûr qu’un module actif.
Un module premium payant est-il à l’abri de ce risque ?
Non. CVE-2023-28121 concernait WooCommerce Payments, un module officiel maintenu activement. Le prix ou le sérieux de l’éditeur réduisent le risque mais ne l’éliminent jamais complètement.
Comment savoir si une extension a été intégrée à l’intérieur de mon thème sans que je le sache ?
C’est un point souvent invisible depuis le back-office standard. Je vérifie directement dans les fichiers du thème la présence de bibliothèques tierces embarquées, comme ce fut le cas pour Slider Revolution dans de nombreux thèmes premium.
À quelle fréquence faut-il vérifier ses modules ?
Une vérification à chaque mise à jour majeure du cœur du CMS, et un contrôle général au moins tous les trimestres, permet de repérer un module à l’arrêt avant qu’il ne devienne un problème.