Category: Uncategorized

WordPress fait tourner plus de 40 % des sites web dans le monde, et la quasi-totalité des incidents de sécurité qui le touchent ne viennent pas du cœur du logiciel, mais des extensions installées dessus. Le constat revient chaque année dans les rapports du secteur : les plugins et les thèmes concentrent l’essentiel de la surface d’attaque réelle d’un site WordPress.

Le décalage entre publication et découverte

Une vulnérabilité dans un plugin n’est pas toujours connue au moment où elle existe. Un chercheur en sécurité la découvre, la signale au développeur de façon responsable, le développeur publie un correctif, puis la vulnérabilité est référencée publiquement avec un identifiant CVE (Common Vulnerabilities and Exposures) dans des bases comme la National Vulnerability Database ou des bases spécialisées WordPress comme WPScan ou Patchstack.

Ce délai, entre la sortie du correctif et le moment où l’administrateur du site l’applique réellement, est exactement la fenêtre que les attaquants automatisés exploitent. Une fois une CVE publiée, des scanners de masse commencent à sonder tous les sites WordPress accessibles pour repérer ceux qui tournent encore avec la version vulnérable. Ce n’est pas une attaque ciblée : c’est un ratissage automatique qui ne demande aucune compétence particulière à celui qui le lance.

Pourquoi la mise à jour automatique ne suffit pas toujours

WordPress propose des mises à jour automatiques pour le cœur et, depuis plusieurs versions, pour les plugins si l’option est activée. Mais dans la pratique, beaucoup de sites gardent cette option désactivée par prudence, pour éviter qu’une mise à jour casse une fonctionnalité en production sans supervision humaine. Résultat : la mise à jour existe, elle est disponible, mais personne ne l’applique tant que personne ne va vérifier manuellement la liste des plugins installés.

Sur un site avec quinze ou vingt extensions actives, ce qui est courant, cette vérification manuelle régulière est rarement faite avec la rigueur qu’elle demanderait. On lance l’extension une fois à l’installation et on l’oublie, jusqu’au jour où elle devient le point d’entrée d’un incident.

Ce qu’un scan de vulnérabilités doit apporter concrètement

Un scan utile ne se contente pas de dire « vulnérabilité trouvée ». Pour être exploitable par quelqu’un qui gère le site, il doit donner l’identifiant CVE précis, la sévérité réelle (une faille XSS n’a pas le même impact qu’une exécution de code à distance), et un lien vers la source qui documente le problème, pour que l’administrateur puisse juger lui-même de l’urgence plutôt que de faire confiance aveuglément à un score automatique.

L’autre point qui change tout en pratique, c’est la fréquence. Un scan manuel ponctuel donne une photo à un instant T, qui devient obsolète dès qu’une nouvelle CVE sort sur l’un des plugins installés. Un scan automatisé qui tourne chaque jour et qui alerte uniquement quand quelque chose de nouveau apparaît change la nature du travail : on passe d’une vérification qu’il faut se souvenir de faire à une alerte qui arrive d’elle-même.

Sources utiles pour qui veut suivre ce sujet de près : le flux de vulnérabilités de WPVulnerability, les bulletins de sécurité officiels sur WordPress.org, et le guide de durcissement de l’OWASP sur WordPress.

Un sous-domaine oublié est rarement vide. Quand une entreprise arrête d’utiliser GitHub Pages, Heroku, S3 ou un service équivalent sans supprimer l’enregistrement DNS qui pointait dessus, elle laisse une porte ouverte derrière elle. Le principe du subdomain takeover tient en une phrase : un enregistrement CNAME pointe vers une ressource cloud qui n’existe plus, et n’importe qui peut recréer cette ressource à l’identique pour récupérer le sous-domaine.

Pourquoi ça marche

La plupart des hébergeurs cloud valident la propriété d’un nom de domaine en vérifiant simplement qu’un CNAME pointe vers leur service. Ils ne vérifient pas qui a créé ce CNAME, ni quand. Si demo.exemple.com pointe vers exemple.github.io et que ce dépôt GitHub Pages a été supprimé, il suffit à un attaquant de créer un nouveau dépôt du même nom sur son propre compte GitHub pour que demo.exemple.com serve son contenu à lui, avec un certificat TLS valide signé pour le domaine de la victime.

Ce n’est pas un scénario théorique. Le projet Can I take over XYZ recense plus d’une soixantaine de services cloud vulnérables à ce pattern, et HackerOne publie régulièrement des rapports de ce type dans son Hacktivity.

Ce que ça permet à un attaquant

Une fois le sous-domaine récupéré, les usages malveillants sont nombreux : phishing sous un nom de domaine de confiance, contournement de règles de Content Security Policy qui autorisaient ce sous-domaine, vol de cookies si le sous-domaine partage le même domaine parent qu’une application sensible, ou simple atteinte à la réputation si le contenu affiché est désobligeant. Le détail technique précis dépend du service concerné, mais le résultat est toujours le même : un domaine qui appartient à l’entreprise sert du contenu qu’elle ne contrôle plus.

Pourquoi c’est difficile à détecter soi-même

Le problème ne vient presque jamais d’une négligence ponctuelle. Il s’accumule avec le temps : un stagiaire qui monte une démo sur Heroku, un sous-domaine de test créé pour un salon professionnel, un ancien prestataire qui avait configuré un bucket S3. Chaque sous-domaine individuellement a une raison d’exister au moment de sa création. Le risque apparaît des mois ou des années plus tard, quand la ressource cloud associée est supprimée mais que personne ne pense à retirer le CNAME correspondant.

Un audit manuel suppose de lister tous les sous-domaines existants (pas seulement ceux qu’on utilise encore), de vérifier chaque CNAME, et de tester si la ressource cible répond encore. Sur un domaine avec plusieurs dizaines de sous-domaines accumulés au fil des années, ce travail devient vite fastidieux à refaire à chaque audit.

Deux approches pour surveiller ça

La première consiste à tester une liste de sous-domaines courants (www, blog, shop, api, mail…) et à vérifier si l’un d’eux pointe vers une ressource abandonnée. Ça couvre les cas les plus fréquents sans nécessiter d’accès particulier.

La seconde consiste à interroger directement la zone DNS réelle via l’API du fournisseur (Cloudflare ou Route53, par exemple), ce qui donne une vue exhaustive sans dépendre d’une liste de noms devinés et fonctionne même derrière un proxy qui masque les enregistrements publics.

Dans les deux cas, l’essentiel est de refaire la vérification régulièrement, pas une seule fois à la mise en place.