Il y a quelques jours, j’ai remarqué une activité inhabituelle sur l’un des sites WordPress que j’ai en maintenance. En consultant les logs, j’ai découvert des centaines de tentatives de connexion à l’administration du site, en très peu de temps, une journée exactement. L’attaque ne passait pas par la page d’administration habituelle (/wp-admin ou /wp-login.php), car je déplace toujours la page de connexion à l’administration des sites WordPress. Je me suis donc posé la question de savoir comment cela était possible. Comment les attaquants avaient accès à cette page d’authentification ? En creusant un peu et à l’aide des copains du Slack, ces derniers m’ont mise sur la piste du fichier xmlrpc.php. J’ai donc décidé d’écrire cet article, car je me dis que ça peut servir à d’autres.
À quoi sert le fichier xmlrpc.php ? Faut-il le désactiver ?
On l’ignore souvent, mais ce petit fichier est présent sur tous les sites WordPress, je l’ai déjà vu plein de fois, à force d’installer des sites WordPress. Mais il est vrai que je ne m’étais jamais vraiment attardée dessus.
L’origine de ce petit fichier est qu’il permettait de faciliter la communication entre WordPress et des applications externes, mais il est apparemment devenu au fil du temps une cible privilégiée des attaques automatisées.
Le protocole XML-RPC, pour XML Remote Procedure Call, permet à des programmes d’envoyer des commandes à distance à un site web. Concrètement, on envoie une requête HTTP contenant du code XML. HTTP est le protocole qui permet de transporter des requêtes. Tandis que le XML sert à décrire des informations en utilisant des balises qui encadrent les informations. Ainsi, le site interprète la requête qu’on lui a envoyée et exécute la commande demandée.
Pendant de nombreuses années, ce mécanisme a facilité la connexion entre WordPress et d’autres services. Puis, l’arrivée de l’API REST, une interface de communication entre les applications, plus moderne et mieux sécurisée, a progressivement rendu le XML-RPC obsolète. Malgré cela, il reste activé par défaut sur les installations, pour notamment permettre la compatibilité avec d’anciens outils.
API pour Application Programming Interface
REST pour REpresentational State Transfer
Le fichier xmlrpc.php : point d’entrée souvent exploité
Le fichier xmlrpc.php est effectivement souvent utilisé comme vecteur d’attaque. Même si l’accès au tableau de bord ou à la page de connexion du site a été déplacé, il reste accessible à l’adresse https://votresite.com/xmlrpc.php. Un pirate peut donc s’en servir pour tenter de se connecter à l’administration sans jamais passer par la page de login habituelle.
Vous pouvez taper https://votresite.com/xmlrpc.php pour vérifier si ce fichier est accessible pour vos sites web. S’il l’est vous aurez le message suivant dans votre navigateur :
Ça, c’est mauvais signe !
On fait face à deux types d’abus. Le premier concerne les attaques par force brute. En envoyant des requêtes XML-RPC répétées, un attaquant peut tester de nombreux couples identifiant/mot de passe jusqu’à trouver le bon. Certaines méthodes permettent d’envoyer des dizaines de tentatives dans une seule requête. Le second type d’abus concerne les pingbacks, une fonctionnalité utilisée pour signaler les liens entre sites. Les pirates détournent parfois cette fonction pour mener des attaques par déni de service (DDoS) en utilisant le site comme relais.
Rediriger l’url du formulaire d’accès au tableau de bord ne suffit pas.
Nous pouvons penser qu’en masquant ou en redirigeant la page /wp-admin, cela empêche toute tentative de connexion. Force est de constater que cela ne suffit pas. En réalité, xmlrpc.php fonctionne de manière totalement indépendante. Tant que ce fichier reste accessible sur le serveur, il accepte les requêtes externes et peut être utilisé pour s’authentifier. Autrement dit, déplacer la page de connexion ne sert à rien si cette porte secondaire reste grande ouverte.
Quand conserver le protocole XML-RPC
Dans certains cas, il convient de garder l’accès à ce fichier, notamment si votre site doit communiquer avec d’autres applications. Par exemple, vous en aurez besoin si vous utilisez Jetpack. Mais dans ce cas, il est essentiel de le protéger.
On peut limiter les risques par exemple en mettant en place un pare-feu applicatif (WAF), une authentification à deux facteurs pour les comptes administrateurs et une limitation du nombre de tentatives de connexion.
Quand et comment désactiver le protocole XML-RPC
Si vous n’utilisez pas d’application mobile WordPress, ni aucun outil externe nécessitant ce protocole, la solution la plus sûre consiste à désactiver complètement le XML-RPC. Plusieurs méthodes existent.
- Vous pouvez bloquer directement l’accès au fichier au niveau du serveur, via le fichier .htaccess en en ajoutant le code suivant pour Apache, avant le bloc BEGIN WordPress :
<Files xmlrpc.php>
Require all denied
</Files>2. Vous pouvez ajouter sinon, ajouter, dans le fichier functions.php :
add_filter('xmlrpc_enabled', '__return_false');3. Autre solution, si votre site est hébergé chez o2switch, le ModSecurity est activé sur votre hébergement, ce qui protège directement l’accès à ce fichier. Dans le cas où ModSecurity serait désactivé pour une raison ou une autre, vous pouvez le désactiver l’accès au fichier xmlrpc depuis le cPanel, grâce à l’outil WP Tiger, en allant dans Sécurité et en activant le toggle permettant de bloquer l’accès.
4. Enfin, quatrième solution, en ajoutant une extension de sécurité sur votre site, qui propose de bloquer l’accès à ce fichier.
En conclusion, le fichier xmlrpc.php a rendu de fiers services, mais il représente aujourd’hui un risque inutile sur la plupart des sites. Si tu n’en as pas l’usage, il vaut mieux le désactiver et éviter ainsi qu’il ne serve de porte d’entrée à des attaques. Si vous devez le conserver, il doit être strictement encadré par des règles de sécurité solides. Dans tous les cas, il ne faut pas se laisser tromper par une simple redirection du tableau de bord : la vraie protection passe par la maîtrise de ce que ton site laisse accessible au monde extérieur.
