Le week-end dernier, j'ai reçu simultanément trois commentaires plutôt originaux à modérer sur ce site. En effet, ces derniers tentaient d'exploiter une vulnérabilité connue sur les deux plugins de cache les plus populaires, W3 Total Cache et WP Super Cache. Cette faille de sécurité a été reportée il y a un an environ par kisscsaby sur le forum WordPress, et a fort heureusement été totalement corrigée depuis. J'ai tout de même souhaité vous en parler car je l'ai trouvée intéressante à étudier et aussi parce qu'elle reste active sur les nombreux sites non mis à jour...
Cette attaque s'appuie sur plusieurs fonctions (mfunc, mclude, et dynamic-cached-content) présentes sur les versions vulnérables (W3TC ≤ 0.9.2.8 ou WPSC ≤ 1.2), et permet d'exécuter un code PHP arbitraire sur le serveur. Autant dire que l'on peut tout faire ! Pour comprendre, il faut savoir qu'un site WordPress avec une version vulnérable d'un de ces plugins va exécuter le code PHP situé à l'intérieur de la balise ouvrante mfunc. Par exemple, le code <!--mfunc echo PHP_VERSION; -–><!–-/mfunc-–>
va afficher la version de PHP utilisé.
Cette fonctionnalité permet initialement au développeur du site d'indiquer les éléments qui ne doivent pas être mis en cache par le plugin, comme par exemple la date ou le temps de génération de la page. Le code compris dans cette balise est alors exécuté à chaque fois, tandis que le reste de la page est mis en cache.
Le problème est que WordPress autorise par défaut l'utilisation d'un certain nombre de balises HTML dans les commentaires, y compris les balises de commentaire HTML (<!--
et -->
). Il est donc possible pour un visiteur malveillant d'injecter des balises mfunc dans le site, et donc du code arbitraire, en postant un simple commentaire comportant cette balise. WordPress ne la filtrera pas puisqu'elle sera interprétée comme un simple commentaire HTML, et elle sera donc stockée en base de données. En revanche, lorsque la page affichant le commentaire sera rechargée, le plugin de cache exécutera le code PHP intégré conformément à la fonctionnalité précédemment décrite.
Analyse détaillée de l'attaque
Regardons maintenant plus en détail les tentatives d'attaques que j'ai reçues. Voici tout d'abord le contenu complet des commentaires que l'on a tenté de déposer :
On peut voir que l'attaque vise à évaluer un code PHP encodé en base 64. Mais qu'y a-t-il derrière cette chaîne de caractères imbuvable ? Le décodage en utilisant la fonction base64_decode
nous donne ceci :
L'objectif est donc d'écrire dans le fichier wp-content/cache/qwkmrn.php le code PHP suivant :
Le code est pollué par des commentaires inutiles que l'on peut retirer simplement en utilisant la fonction php_strip_whitespace
ou la commande php -w. Voici ce que cela donne après ce nettoyage :
Une fois encore, on se retrouve face à une évaluation d'un code encodé en base64. Après un second décodage, on obtient le code suivant :
Le code est encore une fois pollué par des commentaires inutiles. Mais au final, après nettoyage, on obtient un code très simple :
L'attaquant dispose alors d'un shell PHP qui va lui permettre d’exécuter à distance les commandes qu'il souhaite simplement en les passant en paramètre de la page http://sitecible.com/wp-content/cache/qwkmrn.php?nmdxp=. Une backdoor a été introduite, et votre site se retrouve totalement aux mains du pirate...
Comment se protéger ?
Tout d'abord, si vous utilisez toujours une version vulnérable (W3TC ≤ 0.9.2.8 ou WP Super Cache ≤ 1.2), il est indispensable que vous mettiez immédiatement à jour votre site. Ensuite, vous pouvez mettre en place un système de filtrage des spams sur les commentaires, tel qu'un captcha, un honeypot ou le plugin Akismet. Enfin, assurez-vous également que tous les commentaires passent par une étape de modération, ou, à défaut, utilisez un service externe tel que Disqus.
NB : Le code est volontairement sous forme d'image, ce serai bête de risquer de s'auto-attaquer...
Article très intéressant !
Merci
Intéressant mais complexe !
Cette extension ressort souvent dans wpvuln au niveau des failles, à croire qu'ils ne vérifient jamais avant de push en production !
Très sympa mais comme dit kiwi c'est compliqué :p
C'est toujours utilisable sur PHP7? Ca a surment était patché il y a un moment...
Oui cela a même été corrigé avant la publication de l'article comme écrit en préambule. En revanche la technique d'obscuration du code reste un classique encore utilisé dans certains codes malveillants.
Les fameux commentaires avec des "alert" js aussi ...
Merci pour cet article