Un guide définitif sur XMLRPC pour WordPress (+ Comment le désactiver)

La sécurité des sites Web est une chose difficile à résoudre de la bonne manière. Plus précisément avec les problèmes de sécurité liés au XML-RPC – couramment exploité dans les attaques sur les sites WordPress. Il y a beaucoup d'informations disponibles sur Internet proposant toutes sortes de solutions, mais lesquelles sont correctes ? Cet article explique comment, les solutions disponibles et quelle est réellement la meilleure solution. Plongeons-nous !

XMLRPC est plus ancien que WordPress lui-même. Ce système a été introduit dans WordPress pour lutter contre le dilemme de la lenteur de la connexion Internet en aidant les utilisateurs à rédiger de nouveaux messages hors ligne, puis à les télécharger sur le serveur. La possibilité de connecter WordPress à distance avec d'autres applications n'était possible qu'avec le fichier xmlrpc.php.

Même certains développeurs expérimentés ne comprennent pas parfaitement XMLRPC et les menaces de sécurité qui y sont associées. Il est fort possible que le ou les sites que vous gérez aient un fichier XMLRPC actif qui nécessite votre attention immédiate, mais vous ne pouvez exécuter un plan d'action efficace qu'après avoir su comment XMLRPC est exploité et quelle est la meilleure façon de le gérer en toute sécurité.

Bien que WordPress ait maintenant sa propre API REST, le fichier xmlrpc.php est toujours présent à l'intérieur du noyau et est activé par défaut exposant le site WordPress à diverses cyber-attaques. Dans cet article, nous apprendrons l'utilisation de ce fichier, les vulnérabilités qui y sont associées et comment gérer cela sans mettre en danger la sécurité de votre site.

Qu'est-ce qu'un fichier xmlrpc.php ?

Dans sa forme la plus simple, XML-RPC (Remote Procedure Call) a été créé pour la communication multiplateforme. Ce protocole permet d'effectuer des appels de procédure en utilisant HTTP comme transport et XML comme encodeur. Le client effectue ces appels en envoyant une requête HTTP au serveur et reçoit la réponse HTTP en retour. XML-RPC invoque des fonctions via une requête HTTP, puis ces fonctions effectuent certaines actions et envoient des réponses codées en dur en retour.

Comparons cela avec un appel d'API REST pour bien comprendre le concept.

REST utilise des paramètres d'URL pour identifier les ressources tandis que RPC utilise les paramètres de requête pour fournir des arguments de fonction.

WordPress a utilisé XMLRPC pour permettre à ses utilisateurs d'interagir avec leur site à distance. Il l'utilise toujours pour alimenter son application mobile et pour prendre en charge des plugins comme JetPack, WooCommerce, etc. L'utilisation du fichier xmlrpc.php a ses inconvénients, mais le désactiver complètement est-il la seule solution viable ? Pour répondre à cela, nous devons d'abord examiner les vulnérabilités qui y sont associées et quelles sont les solutions disponibles pour les éviter.

À quel point les pirates informatiques peuvent-ils être vicieux avec le fichier xmlrpc.php ?

À l'aide de XMLRPC, les pirates exploitent les appels de procédure à distance (RPC) et invoquent des fonctions pour récupérer les données qu'ils souhaitent. Dans la majorité des sites WordPress, le fichier xmlrpc.php est facilement traçable, et juste en envoyant des données XML arbitraires, les pirates contrôlent le site pour exécuter le code qu'ils ont préparé pour exécuter un certain type d'attaque.

Pour comprendre comment WordPress XMLRPC est compromis, examinons les cyberattaques les plus populaires qui lui sont associées.

Attaque de force brute

Dans l'attaque Bruteforce, le pirate essaie de deviner le nom d'utilisateur et le mot de passe corrects en exécutant de nombreuses tentatives de connexion. Malheureusement, un grand nombre de sites WordPress utilisent des mots de passe administrateur faibles ou n'ont aucune couche de sécurité ajoutée pour arrêter les attaquants. Ces sites sont facilement compromis par ce type d'attaque.

D'autres utilisent un mot de passe fort et ont également mis en place des mécanismes de sécurité tels que reCaptcha et le blocage IP automatique qui est efficace contre les attaques par force brute mais si le pirate décide d'utiliser XMLRPC ; elle n'a même pas besoin d'accéder à l'administrateur WordPress.

Un outil très courant de Kali Linux, WPSCAN est utilisé pour énumérer tous les noms d'utilisateur et une fois que c'est fait, les pirates forcent brutalement le mot de passe en utilisant le fichier xmlrpc.php en envoyant la requête HTTP suivante au site victime.

POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

Dans l'exemple ci-dessus, un pirate peut envoyer des milliers de variantes jusqu'à ce qu'il récupère le mot de passe correct.

La réponse suivante est renvoyée contre la demande ci-dessus. La réponse contient le code d'erreur et un message clair indiquant que le nom d'utilisateur et le mot de passe essayés étaient incorrects. C'est une indication claire qui indique au pirate de réessayer jusqu'à ce que le mot de passe correct soit trouvé.

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

La réponse a renvoyé le code HTTP 200 et le message indiquant que le nom d'utilisateur et le mot de passe fournis étaient incorrects. En passant par le canal XMLRPC, un hacker n'a pas à se soucier des reCaptchas ni des plugins de limitation des tentatives de connexion. Elle peut continuer à exécuter les variantes jusqu'à ce que le mot de passe correct soit récupéré.

Remarque : Les attaques par force brute sont gourmandes en ressources et entraînent également des problèmes de performances. Le processus d'essai et d'erreur s'exécute en boucle pendant une période plus longue, ce qui peut occuper votre serveur pour servir les visiteurs réels. Cette consommation de ressources inutile fait que les serveurs consomment plus d'énergie.

Attaque DDoS

Le déni de service distribué (DDoS) est l'une des cyberattaques les plus mortelles qui peuvent paralyser le serveur en le frappant avec des centaines et des milliers de requêtes simultanées. Les pirates utilisent la fonction pingback de WordPress avec le fichier xmlrpc.php pour exécuter de telles attaques.

Idéalement, le pirate cible le terminal ou une page qui peut être visitée plusieurs fois et met plus de temps à répondre. De cette façon, un seul hit peut avoir un impact maximal sur les ressources du serveur et dans notre cas, XMLRPC sert bien le pirate en exposant de tels points de terminaison.

Plusieurs sites WordPress déjà compromis sont utilisés pour exécuter la méthode pingback.ping afin de cibler une seule victime. Les requêtes HTTP GET et POST accablantes bloquent le trafic normal et finissent par planter le serveur.

Tout d'abord, le pirate vérifie si le fichier xmlrpc.php est activé ou non en envoyant la requête suivante.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 175

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>

Une fois qu'il est confirmé que le XMLRPC est activé sur le site Web cible, l'attaquant commence à le frapper en utilisant le réseau de sites exploités pour envoyer plusieurs demandes de pingback à un site victime. Cela peut être automatisé à partir de plusieurs hôtes et être utilisé pour provoquer une attaque DDoS de masse sur le site victime.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>

Attaque de port intersite (XSPA)

Les attaques de ports intersites (XSPA) sont très courantes dans lesquelles le pirate injecte le script malveillant pour récupérer des informations sur les ports TCP et les adresses IP. Dans le cas de WordPress, XMLRPC est utilisé avec son mécanisme de pingback pour contourner tout masquage IP tel que le WAF de base comme Cloudflare.

Lors d'une attaque XSPA, le pirate utilise la méthode pingback.ping pour renvoyer un message sur un site Web cible qui, en retour, envoie l'adresse IP en réponse. Hacker utilise un renifleur pour créer le point de terminaison pour envoyer le pingback et une URL en direct d'un article de blog.

Les pirates envoient la requête suivante depuis son serveur.

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

Si la réponse contient faultCode et une valeur supérieure à 0, cela signifie que le port est ouvert pour que vous commenciez à envoyer les paquets HTTP directement.

Méthodes inefficaces de blocage des attaques XMLRPC

Jusqu'à présent dans l'article, nous avons établi que le fichier xmlrpc.php est sujet à de graves cyberattaques telles que DDoS, Bruteforce et Cross-site Port Attack, il est donc crucial de le gérer correctement pour bloquer ces attaques. .

En supprimant complètement le XMLRPC

Vous pouvez simplement supprimer le fichier XMLRPC qui fera que votre serveur lancera des erreurs 404 à quiconque essaiera d'y accéder. L'inconvénient de cette solution est que le fichier sera recréé à chaque mise à jour de WordPress.

En désactivant complètement le XMLRPC

L'autre option plus viable consiste à désactiver le fichier xmlrpc.php . Vous pouvez le faire en ajoutant simplement le bloc de code dans votre fichier .htaccess . Assurez-vous de le faire avant les règles .htaccess sans changement ajoutées par WordPress.

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

Cela désactivera le fichier xmlrpc.php pour chaque application ou service qui l'utilise. Vous pouvez mettre en liste blanche une certaine adresse IP au cas où vous souhaiteriez toujours accéder à votre site WordPress via XMLRPC. Pour cela, vous devez ajouter la commande suivante :

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

Avantages

• Élimine les risques d'abus de XMLRPC dans les cyberattaques.
• Avantages de performance à long terme et économies sur les ressources du serveur.

Les inconvénients

• La désactivation de XMLRPC revient au même que la désactivation de l'accès à distance pour les applications qui utilisent cette version de l'accès à distance. Cela signifie que Jetpack, l'application mobile WP ou toute autre solution qui se connecte à votre site WordPress via XMLRPC ne peut plus se connecter à votre site.
• Le code hérité pour les applications personnalisées peut ne pas fonctionner non plus.

Pourquoi l'installation d'un plugin de sécurité nuit réellement à votre site

Les utilisateurs de WordPress s'appuient souvent sur des plugins pour toute fonctionnalité ou fonctionnalité requise sans trop réfléchir à leur impact sur les performances du site. Il existe plusieurs plugins de sécurité WordPress qui promettent de sécuriser votre site Web contre les problèmes de sécurité liés à XMLRPC, mais en réalité, ils nuisent davantage à votre site.

Voici quelques-unes des raisons pour lesquelles sécuriser votre site avec un plugin n'est pas le meilleur choix.

• Les plugins de sécurité ne sont efficaces qu'au niveau de l'application et ne protègent pas votre serveur contre les attaques.
• Ils ajoutent du code inutile sur votre site qui dégrade ses performances et augmente le temps jusqu'au premier octet (TTFB).
• Certains de ces plugins font plus de mal que de bien et sont utilisés par les pirates pour créer des portes dérobées vers votre site Web.
• Ces plugins nécessitent une gestion fréquente qui ajoute plus de charge de travail.

D'après l'évaluation ci-dessus, aucune des options n'offre une solution idéale pour gérer le problème de sécurité XMLRPC. Cela nous amène aux domaines accélérés. Un service conçu pour résoudre des problèmes complexes liés à la sécurité et bien plus encore. Voyons comment les domaines accélérés peuvent résoudre efficacement le problème XMLRPC pour vous.

Comment Accelerated Domains gère les problèmes XMLRPC pour ses clients ?

Les domaines accélérés résolvent les problèmes complexes de performances, de sécurité et d'évolutivité de la manière la plus efficace. Accelerated Domains offre une sécurité gérée au niveau de l'entreprise qui bloque tout type de cyberattaques, y compris celles associées à XMLRPC.

Le moteur de sécurité intelligent d'Accelerated Domains se trouve devant le serveur et filtre près de 40 % de tout le trafic HTTP. Il détecte même les cyberattaques les plus sophistiquées au début de la chronologie grâce à ses capacités heuristiques intelligentes alimentées par une alimentation continue des données et les connaissances pratiques et l'analyse du trafic de Servebolt. Les domaines accélérés font leur magie sans dégrader en aucune façon les performances de votre site. En fait, il l'accélère.

Le moteur de sécurité proactif Accelerated Domains protège automatiquement votre site Web contre les attaques DDoS. Avec une capacité de réseau de près de 60 Tbps, il est bien équipé pour résister même à certaines des plus grandes attaques DDoS sur Internet. De même, il fournit un mécanisme de défense efficace contre les attaques Bruteforce grâce à une fonction de limitation automatique du débit où le nombre de requêtes générées à partir d'une source unique est identifié et limité pour empêcher les activités malveillantes.

Avantages

• Les domaines accélérés atténuent la majorité des vulnérabilités de sécurité associées à XMLRPC, il n'est donc pas nécessaire de le désactiver.
• Permet à l'utilisateur de continuer à utiliser les plugins comme Jetpack, l'application WooCommerce et d'autres outils qui dépendent du fichier xmlrpc.php.
• Intégration sans tracas sur n'importe quel domaine donc pas besoin de modifier le fichier .htaccess .
• Pas besoin d'installer des plugins supplémentaires.

Les inconvénients

• Il n'en a aucun.

Dernières pensées

Les cyberattaques deviennent chaque jour plus sophistiquées et en tant que webmaster et propriétaire d'entreprise, il est essentiel que vous les compreniez et que vous connaissiez les outils pour y faire face. La majorité des attaques sont évitées grâce à une approche proactive telle qu'une surveillance et une mise à jour constantes du logiciel ou en ajoutant des outils tels que les domaines accélérés qui font tout cela en pilote automatique. Une fois activés, les domaines accélérés filtrent intelligemment le trafic et prennent les mesures nécessaires, le cas échéant, pour protéger votre serveur d'origine et votre site Web contre les cyberattaques.