WordPress a son fanclub. Il fait tourner plus de 40% des sites web, il a son scanner dédié, ses wordlists de plugins maintenues à jour, ses CVE répertoriées en masse, et une communauté offensive qui sort un nouvel outil dès qu’une techno secondaire se rattache de près ou de loin à son écosystème. WPScan, par exemple, énumère plugins, thèmes et versions, et croise tout ça avec une base de vulnérabilités connues. C’est devenu un réflexe tellement ancré qu’on ne se pose même plus la question de l’outil à utiliser sur un audit WordPress.
Drupal, lui, fait tourner une bonne partie des sites institutionnels, de grands groupes, et pas mal de plateformes qui ont quinze ans de bons et loyaux services. Et Drupal n’a pas le luxe de Wordpress. Pas de scanner de référence ni de base de plugins maintenue. On a cherché en se disant qu’on avait juste raté l’outil que tout le monde utilise. Il n’existe pas.
C’est l’histoire qu’on raconte ici, comment on s’est retrouvés pendant un audit Drupal à devoir choisir entre énumérer à la main ou écrire l’outil qui manquait. On a choisi la deuxième option, et c’est devenu DrupEnum.
Enumérer et toujours enumérer
Avant de chercher la moindre faille, la première vraie étape d’un audit web c’est de savoir ce qui tourne réellement sur la cible. Dans le cas de Drupal, il faut réussir à récupérer les modules qui sont utilisés et la version du CMS.
Drupal va parfois exposer des fichiers de métadonnées par module : les .info.yml sur les versions récentes, les .info sur les plus anciennes. Quand ils sont accessibles publiquement, ils nous permettent de récupérer le nom du module, sa version, et même parfois la contrainte de core associée. Aucune de ces informations n’est une vulnérabilité en soi mais c’est exactement le genre de donnée qui permet de mieux cibler les attaques dans l’audit. On sait quoi vérifier en priorité, quels modules ont un historique contenant des vulnérabilités et donc où chercher en premier.
Sans ça, on audite une boîte noire et on devine, et deviner en sécurité offensive c’est le meilleur moyen de passer à côté de quelque chose.
La quête du tool prodigue
On s’attendait à trouver un outil pour ça, parce que c’est exactement le genre de tâche répétitive qu’on ne devrait jamais refaire à la main. Il existe bien quelques outils de détection de version Drupal, et des scanners génériques qui tentent une poignée de chemins connus. Mais rien qui fasse simplement et correctement ce qu’on voulait de la même façon que WPScan.
La différence avec WordPress n’a rien à voir avec la complexité technique des deux CMS. Elle tient à un seul facteur qui est la taille du marché. Plus une techno est répandue, plus elle attire l’attention offensive, plus l’outillage va suivre. Drupal reste massivement utilisé, mais jamais assez visible pour justifier qu’une communauté entière investisse dans des tools de sécurité comme elle l’a fait pour WordPress. On se retrouve alors avec un CMS qui équipe pourtant des cibles très sérieuses mais qui n’est pas pris au sérieux assez pour avoir l’outil qu’on cherche.
On a écrit DrupEnum
Lorsqu’on a compris qu’on aurait pas un tool servi sur un plateau d’argent pour cet audit, on a décide d’écrire un script rapide pour automatiser l’enumération. Il scrapait drupal.org pour récupérer la liste des modules, puis il les testait un à un sur la plateforme. Le script n’a rien de propre, rien de réutilisable mais ça nous a suffit pour la mission. Sauf qu’au moment de passer à autre chose, on savait que nous ou quelqu’un d’autre se retrouverait un jour ou un autre dans la même situation sur Drupal, à devoir chercher github avant de se résoudre à faire un script temporaire. On a voulu arrêter ce cycle là et donc on a pris le temps d’écrire DrupEnum.
Le principe reste le même, notre outil part d’une liste de noms de modules qui ont été récupérés directement sur le site de Drupal et stockés dans une base qui en contient environ 19 000. Puis, pour chacun, il va tester les chemins où les métadonnées se trouvent généralement :
modules/contrib/<module>/<module>.info.yml
modules/<module>/<module>.info.yml
profiles/contrib/<module>/<module>.info.yml
sites/all/modules/contrib/<module>/<module>.infoQuand un chemin répond et que le contenu ressemble vraiment à un fichier Drupal, l’outil en extrait le nom du module, sa version si elle est présente, et la contrainte de core associée. En quelques secondes, on obtient une vraie photographie de la cible :
Ce qui était auparavant un script fait de bâtons et de roches utile uniquement dans un cas spécifique, est devenu un tool généralisé à tout les serveurs sous Drupal. L’outil est disponible sur GitHub.
Le core du problème
La version du core Drupal est parfois lisible directement depuis un fichier public, et parfois introuvable parce que ces mêmes fichiers ont été retirés, filtrés ou modifiés avant la mise en prod.
DrupEnum croise alors plusieurs sources : les fichiers de changelog quand ils subsistent, les fichiers de configuration exposés par erreur sous sites/default/, et en option un fingerprinting de fichiers statiques du core comparés à une base locale de hashs par version. Quand plusieurs versions matchent les mêmes fichiers, l’outil les classe par nombre de correspondances.
Avec toutes ces façons de récupérer le core, on se retrouve souvent avec une estimation qui est assez précise pour aller vérifier les vulnérabilités présentes sur cette version.
Compter ne suffit pas, il faut attaquer
Une fois les modules identifiés, l’étape suivante est de vérifier s’ils ont des vulnérabilités connues. DrupEnum interroge OSV sur les paquets qui ont été identifiés avec l’option --check-vulns.
Le point qu’on a pris le temps de bien faire, c’est de ne jamais mélanger deux choses très différentes : une advisory qui correspond exactement à la version détectée sur la cible, et l’historique général d’un paquet qui a eu des vulnérabilités par le passé sans être sûr que la version exposée soit concernée. Beaucoup d’outils affichent les deux au même niveau, et ça produit du bruit puisque l’objectif est de récupérer une vulnérabilité qui colle au module présent sur le CMS au moment où on audite. DrupEnum sépare clairement les deux dans sa sortie et l’historique peut rester tout de même une piste à vérifier.
Ce qu’on retient de tout ça
DrupEnum n’est pas parfait, s’il ne trouve aucun module, ça ne veut pas dire qu’il n’y en a aucun, ça veut dire qu’aucun des chemins testés n’était accessible.
Mais le vrai gain n’est pas dans la liste de modules elle-même, il est dans le fait de ne plus jamais être bloqué par l’absence d’un outil dans ce contexte. Sur cette mission, on aurait pu se contenter de rester sur le script fait à la va vite et de se dire que l’on ne reverrait pas Drupal de sitôt. À la place, on a pris le temps de combler le trou.
Chez HDWSec, chaque mission nourrit la suivante. Quand un outil n’existe pas, on l’écrit. C’est comme ça qu’on accumule au fil des années un outillage qu’on ne trouvera pas ailleurs, taillé pour des cas réels rencontrés en mission, par des gens qui savent aussi bien auditer que développer. WordPress aura toujours son armée de scanners. Drupal, maintenant, a au moins le sien.
Le lien du Github : https://github.com/HDW-Sec/DrupEnum